I'm working in SAP ecosystem for more than 12 years. In early 2000 we've small number of customers with small number of named users and low capacity servers (when you look from now). A server with 4 GB RAM was a great server but now even tablets have this amount of memory.
Even the data of customers become larger and larger in time. The ERP version upgrades, Unicode, Enhancement Packages (EHP), new modules, Industry Solutions (IS) made the ERP DB to grow faster.
Problem
Now, customers doesn't have only ERP, but they have BW, Portal, CRM and SCM, SRM,... in their environment.
In every landscape, they have at least Development and Production systems, but mostly Test/Qas added to the landscape.
So, a simple calculation;
ERP: 3
BW: 3
Portal: 3
CRM: 3
-------------
12 SAP Systems.
To consolidate the CPU and RAM power, customers now started to use Virtual Environments (VMWARE, HYPER-V) for their SAP landscapes.
But they've still problems on storage part. You cannot consolidate the database.
So, lets make another simple calculation for the storage for a customer who is live for more than 5 years:
ERP: 150 GB (DEV), 1000 GB (QAS)*, 1200 GB (PRD)
BW: 200 GB (DEV), 750 GB (QAS), 1200 GB (PRD)**
Portal: 50 GB (DEV), 50 GB (QAS), 50 GB (PRD)
CRM: 200 GB (DEV), 400 GB (QAS), 1000 GB (PRD)
* Estimated for a twice/year copy of QAS system from PRD.** We see samples whose BW PRD server has double ERP DB size.So at total ~6500 GB space is required to run the servers. Also, if you're able to compress it by %50, 3500 GB backup space required.
If you add the disaster recovery sites only for production systems you've to add 3500GB which makes the space requirement for SAP solutions to 10TB.
So, you may wonder if there are solutions to descrease the size of the SAP landscape.
Solution(s)
Here are the alternatives for decreasing the storage requirements for SAP solutions:
- SAP Data Archiving
- SAP Platform Migration
- Data Cleaning
- Stopping to work on exiting system and starting a new financial year on a new system
1. SAP Data Archiving
Data archiving is a method of getting data from db tables to flat binary files and deleting the data from db. When you need, you can access the data immediately reading from archiving file.
PROS:
- You don't need to stop production operation
- You can access the data on existing and upgraded versions.
- Data from DB to File is compresses 10 times or more
CONS:
- It has to be held as a seperate project which may take long
- A reorganization is required at the end
- Module consultants and ABAP developers must be involved
- Serious testing for data read required especially from customer reqports/functions.
- Depending on the selected archiving period, space gain is mostly limited below %50 (our experiences)
- Customer tables cannot be included directly as they'v no Archiving Objects.
- Application to Java based systems with XML based DAS (for details
http://help.sap.com/saphelp_nw73/helpdata/en/4c/3a2343b50843b4e10000000a42189e/content.htm)
2. SAP Platform Migration
Platform migration is easiest way to gain storage space in a very short time.
Some databases now provides Row, Unicode and Page compressions to lower the DB size without doing any archiving.
SAP customers buys their DB license from SAP in general and some DB vendors limits the licensed addons for SAP customers.
- DB2 provides ROW compression which compresses SAP database by %50. Details are given in 980067https://service.sap.com/sap/support/notes/816773.
- SQL Server 2008 and especially SQL Server 2008 R2 provides the row, unicode and page compressions without extra cost.
- Not sure the Oracle's 11g but before that release, provided compression is also about %50.
Currently, we're doing migrations from Oracle, DB2 to SQL Server 2008 R2 for 2 reasons:
1. To lower TCO for customers
2. Decrease the DB size dramatically which delays the need for data archiving.
SQL Server 2008 R2 reqiures at least NetWeaver 7.0 Basis SP 14 and a specific Kernel Release to run.
But if your system provides these prerequisites, it is possible to descrese the db size by %80.
We've tested a NetWeaver BW System with size 1700 GB. After migration, the DB size decreased to 350 GB.
You can check other ERP based test results via http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/50c5de8f-282a-2e10-cb8a-a5859a099...
PROS:
- Only Basis guys involved in project
- If you provide enough downtime, you can do the migration within a month
- Almost no end user test reqiured.
- You can combine the unicode conversion with platform migration
- you automatically reqotrganize the db during this procedure
- Applicable to all ABAP and Java based systems
CONS:
- You need time depending on the DB size and hardware power to do the migration. (3-5 TB in 48 hours)
- Certified OS/DB Migration Consultants required who knows the source and target os/db.
3. Data Cleaning
Some customers do this data cleaning to get rid of the unnecessary data and clients but it generally doesn't help to lower the DB size. But in a GSM operator, I see they deleting an unnecessary client lowered the production db size by %50. I guess this is special case for they customer only.
PROS:
- Even no consulting reqiured
- can be done during production operation
CONS:
- Deep functional knowledge required
- At the end, the gain may be low
4. Starting the new Financial Year on a fresh system
I see some distributor companies who copied their developments and customizings as well as the master data to a new system. They upgraded the ERP release on new system and go live with this frash system. Old system is used as an archiving system.
PROS:
- Dramatically may decrease the DB size
- You can correct some problems in business processes in new system before go live.
CONS:
- You've to keep the old system for govermental regulations.
- You've to logon the old system for reporting so you've to keep that server online
Conclusion
Here below is the compatiblity of the options for the types of the systems:
| Method | AS ABAP based | AS Java Based | AS ABAP+Java Based |
| Data Archiving | Compatible | Compatible | Partial Compatible |
| Platform \ Migration-DB2 | Compatible | Compatible | Compatible |
| Platform \ Migration-SQL Server 2008 R2 | Compatible | Compatible | Compatible |
| Data Cleaning | Compatible | Compatible | Compatible |
| Starting on \ New Server | Compatible | Compatible | Compatible |
For the estimated storage benefits, please have a look at the below table for the scenario given above (ERP, BW, Portal and CRM with 3 systems in each landscape):
| Method | Original Size (GB) | Duration | After operation | Gain(%) |
| Data Archiving | 10.000 | at least 6 months | 6.000 | 40 |
| Platform \ Migration-DB2 | 10.000 | 1-3 month | 5.000 | 50 |
| Platform \ Migration-SQL Server 2008 R2 | 10.000 | 1-3 month | 2.000 | 80 |
| Data Cleaning | 10.000 | <variable> | 7.000 | 30 |
| Starting on \ New Server | 10.000 | <variable> | 2.000 | 80 |
Now, SAP provides the Sybase ASE Database as an alternative database to SQL, DB2 and Oracle. In 3 years, HANA will also be provided as a database for all SAP solutions.
But now, if you can get rid of the superstitions for SQL and new databases, you can dramatically lower the storage requirement for your SAP solutions.
By using SAP TDMS like solutions, you can also help to descrease the size required for DEV and QAS systems. But SAP TDMS is suitable for another blog topic 🙂
I'm not fan of any Hardware, Operating System and Database solutions, but also I'm not blind. If it provides and works, why not to use it?
