# 19 – Optimize SAP data usage for storage cost efficiency
**How do you optimize your SAP data usage to minimize your storage and memory-related costs?** Design your database storage, backup, and supporting file systems to consider cost, and regularly evaluate location, retention, and housekeeping strategies.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/latest/sap-lens/design-principle-19.html)
# Best Practice 19.1 – Understand access and retention requirements
Understand the ways in which you access and retain data. Consider active data, document management systems, and backups.
**Suggestion 19.1.1 – Categorize the different types of business data in the SAP system**
By categorizing the different types of data and how frequently data is accessed (data temperature) from a business perspective, it is possible to identify opportunities to archive or offload data from your SAP system to optimize cost.
The following are some of the common data types found in an SAP system:
+ **Reference** — Data for which the values change infrequently, for example, city, country, and exchange rates
+ **SAP Master Data** — Data for which the values change rarely, for example, SAP Customer Master, product
+ **Audit** — Data kept for audit purposes, for example, change logs
+ **Transaction** — Data created as part of day-to-day business operations, for example, sales orders
+ **Analytical** — Data created to support analysis and decision making, for example, monthly sales reporting
Classify the data temperature as follows:
+ **Hot** — Data is accessed frequently
+ **Warm** — Data is not accessed frequently
+ **Cold** — Data is only accessed sporadically
Classify retention requirements as follows:
+ Retain for disaster recovery (DR) purposes
+ Retain for reference purposes
+ Retain for compliance or audit purposes
# Best Practice 19.2 – Delete unnecessary data through regular housekeeping
Reduce your data footprint to save costs by minimizing database size and other filesystem usage through regular housekeeping and reorganization activities.
**Suggestion 19.2.1 – Review sizing and perform regular housekeeping on SAP technical tables**
SAP provides comprehensive guidance on the data management of technical tables. By identifying and addressing the growth of these tables, it is possible to reduce storage and compute costs. This is especially relevant for SAP HANA instances because of the direct relationship between database size and memory requirements.
+ SAP Note: [2388483 - How-To: Data Management for Technical Tables](https://launchpad.support.sap.com/#/notes/2388483) [Requires SAP Portal Access]
Use the "largest table" SQL Statements referenced to get comparative table sizes, in particular those marked as Basis tables. A frequent example in established SAP customers is the high number of completed SAP workflow items which could be deleted or archived. Housekeeping prior to a migration can also improve timelines and performance. If using SAP HANA, the report `/SDF/HDB_SIZING` can provide cleanup details and anticipated disk requirement.
**Suggestion 19.2.2 – Control filesystem growth through automatic or regular cleanup of logs, traces, interface files, and backups**
As storage costs are driven by usage, there are opportunities to optimize the baseline usage, in addition to the multiplier effect of copies and backups of files which are no longer useful for fault analysis.
+ SAP Note: [2399996 - How-To: Configuring automatic SAP HANA Cleanup with SAP HANACleaner](https://launchpad.support.sap.com/#/notes/2399996) [Requires SAP Portal Access]
# Best Practice 19.3 – Use compression, reorganization, and reclaim strategies
All databases supported by SAP provide mechanisms for reclaiming space. These mechanisms should be part of regular maintenance activities to minimize cost increases associated with extending memory or EBS volumes.
**Suggestion 19.3.1 – Use database compression**
Compression is a default characteristic in SAP HANA. Use of compression in other databases might require additional licenses but should be explored for cost and performance benefits. The following notes provide a starting point for the various databases, but refer to SAP and database documentation for additional information.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/latest/sap-lens/best-practice-19-3.html)
**Suggestion 19.3.2 – Use database reorganizations and reclaim operations**
Space which is unused within the database, due to organic use or targeted archive and cleanup activities, might require a reorganization or reclaim operation to realize the space savings. By reclaiming space regularly, you will reduce the overall growth and requirement for additional storage or memory. The following notes provide a starting point for the various databases, but refer to SAP and database documentation:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/latest/sap-lens/best-practice-19-3.html)
# Best Practice 19.4 – Review backup strategy for improvements
When running SAP on AWS, you should evaluate your approach to backups and retention to optimize the costs associated with location, retention, and recovery.
**Suggestion 19.4.1 – Evaluate the locations of your backups**
Amazon S3 is the suggested long-term storage solution for your SAP system backups for its low cost, durability, and storage class options. To copy the data on your Amazon EBS volumes to Amazon S3, you can use point in time snapshots, integrated database tools, or direct API calls to transfer data.
Snapshots are *incremental* backups, which means that only the blocks on the device that have changed after your most recent snapshot are saved. This minimizes the time required to create the snapshot and saves storage costs by not duplicating data.
Database backup solutions require a knowledge of database state to ensure consistency. AWS provides an SAP HANA backup solution (AWS Backint Agent for SAP HANA) at no additional cost which integrates directly with Amazon S3. For other SAP supported databases, there are database vendors or third-party provided backup tools available which support backing up directly to Amazon S3.
+ SAP Documentation: [Featured backup solutions](https://www.sap.com/dmc/exp/2013_09_adpd/enEN/#/solutions?search=backup)
For ad-hoc requirements or as a staging area, it might be necessary to first back up to Amazon EBS. For these use cases, an `ST1` volume type is a low-cost HDD volume which provides throughput and performance characteristics suitable for backups. Selecting `ST1` can reduce your overall storage costs when the need to back up the SAP database to disk is required.
+ AWS Documentation: [Amazon EBS volume types](https://aws.amazon.com/ebs/features/#Amazon_EBS_volume_types)
If using Amazon EFS for backups, consider EFS-Infrequent Access. This storage class reduces storage costs for files that are not accessed every day. Amazon EFS One Zone-Infrequent Access is not recommended for backups due to the data only residing in one Availability Zone.
**Suggestion 19.4.2 – Review and implement a retention policy for standard backups**
To control costs, you need to implement a retention policy aligned with your business requirements that covers the storage services in use.
Amazon S3 offers a range of storage classes designed for different use cases with characteristics such as cost per GB, minimum storage duration charge, and retrieval fee (where applicable). Understanding the retention and access requirements for your backups will help determine which storage class is most suitable to meet your requirements.
S3 Lifecycle policies can be used to automatically transfer to a different storage class without any changes to your application. For example, backups with shorter retention periods might be better suited to S3 Standard than S3-IA or Amazon Glacier options due to the minimum storage duration charges and retrieval fees associated with these classes. Backups with longer retention periods such as monthly backups for audit purposes are better suited to S3-IA or Amazon Glacier dependent on the required retention period.
Amazon Data Lifecycle Manager can be used to automate the creation, retention, and deletion of EBS snapshots and EBS-backed AMIs.
Amazon EFS lifecycle management automatically manages cost-effective file storage for your file systems.
+ AWS Documentation: [Amazon S3 Storage Classes](https://aws.amazon.com/s3/storage-classes)
+ AWS Documentation: [Amazon S3 Storage Classes Infographic](https://aws.amazon.com/s3/storage-classes-infographic/)
+ AWS Service: [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html) for EBS snapshots and EBS-backed AMIs
+ AWS Documentation: [Amazon EFS Lifecycle Management](https://docs.aws.amazon.com/efs/latest/ug/lifecycle-management-efs.html)
+ AWS Service: [AWS Backup](https://aws.amazon.com/backup/)
**Suggestion 19.4.3 – Create a strategy for ad-hoc backups**
Ad-hoc backups of a system or component might be required prior to a change or as a reference for system state at a particular point in time. When the required retention does not align with your standard lifecycle policy, you might need to adopt a separate schedule or process for ensuring that storage usage and deletion is cost effective for the individual requirements of that backup.
+ AWS Documentation: [Amazon S3 Storage Lifecycle Management](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)
+ AWS Documentation: [Amazon EBS Snapshots Archive](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-archive.html)
**Suggestion 19.4.4 – Review backup setup against recovery approach**
Backups are used to revert a system to a previous point in time and to guard against failure scenarios. Ensuring cost efficiency through a robust, but not excessive, use of backup storage requires that you review the recovery approach. Challenge assumptions on requirements for older more granular backups. Determine if these earlier backups would be required in the event of a recovery.
For example, it is a valid strategy to use both database and file system backups. However, if the primary mechanism for recovery is using database restore tools, there might be opportunities to optimize costs by reducing the retention or deleting snapshot backups for some volumes.
+ AWS Documentation: [Amazon EBS snapshots](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ AWS Documentation: [AWS Trusted Advisor best practice checklist](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
# Best Practice 19.5 – Consider tiering options for live data
The primary driver of compute cost with SAP HANA is the amount of memory required. Therefore, the use of data offload and tiering options can drive the compute costs down. Although other databases might have tiering options, these have not been highlighted here. Consult with your database provider to understand the available options.
**Suggestion 19.5.1 – Evaluate dynamic tiering, extension nodes, and near-line storage (NLS) for SAP HANA OLAP-based workloads**
SAP HANA dynamic tiering is an optional add-on to the SAP HANA database to manage historical data. The purpose of dynamic tiering is to extend SAP HANA memory with a disk-centric columnar store (as opposed to SAP HANA’s in-memory store) for managing infrequently accessed data. Dynamic tiering can only be used for native SAP HANA use cases and not Business Warehouse (BW) on HANA or BW/4 HANA use cases
An SAP HANA extension node is a special purpose SAP HANA worker node that is specifically set up and reserved for storing warm data. An SAP HANA extension node allows you to store warm data for your SAP Business Warehouse (BW) or native SAP HANA analytics use cases. The total amount of data that can be stored on the SAP HANA extension node ranges from 1x to 2x of the total amount of memory of your extension node.
SAP BW Near-Line Storage (NLS) with SAP IQ allows you to store cold data outside of the BW on HANA or BW/4 HANA database. NLS moves the cold data from the HANA database to store on storage on the SAP IQ Server.
+ AWS Documentation: [SAP Data Tiering](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-data-tiering.html)
**Suggestion 19.5.2 – Evaluate data aging and SAP HANA Native Storage Extension (NSE) for OLTP-based workloads**
Data aging helps free-up SAP HANA memory by storing less frequently accessed data in the disk area.
+ AWS Documentation: [SAP Data Tiering](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-data-tiering.html)
**Suggestion 19.5.3 – Consider the use of data lakes for large volumes of analytical data**
When analyzing SAP and non-SAP data, S3-based data lakes provide a cost-effective option for data storage.
+ AWS Documentation: [SAP OData connector for Amazon AppFlow](https://docs.aws.amazon.com/appflow/latest/userguide/sapodata.html)
+ SAP on AWS Blog: [Building data lakes with SAP on AWS](https://aws.amazon.com/blogs/wsforsap/building-data-lakes-with-sap-on-aws/)
# Best Practice 19.6 – Evaluate archiving and offloading options
By considering options to archive infrequently accessed data or offload large objects to near-line storage, you can reduce your infrastructure and backup costs.
**Suggestion 19.6.1 – Implement archiving for large tables with infrequently accessed data**
Specifically for SAP HANA databases, there are cost benefits of managing your database growth using archiving strategies.
+ SAP Documentation: [Data Archiving](https://help.sap.com/viewer/6c8d90ed795242279e9103a8acad9cbe/LATEST)
**Suggestion 19.6.2 – Evaluate the archiving tools that support Amazon S3 as a destination**
Amazon S3 is designed to be highly available and durable and offers a wide range of cost-effective storage classes. This makes it ideal for storing SAP archive data with the lowest total cost of ownership (TCO).
+ AWS Documentation: [Amazon S3 Storage Classes](https://aws.amazon.com/s3/storage-classes)
+ SAP Documentation: [SAP Certified Archiving Solutions](https://www.sap.com/dmc/exp/2013_09_adpd/enEN/#/solutions?filters=v:296)
**Suggestion 19.6.3 – Use a data management system for large objects**
Understand the options and cost benefits for offloading and managing data outside of the SAP database for large objects, such as invoices and images. Consider the business requirements for accessing the data, the implementation effort and the ongoing management complexity.
Large objects will increase your database size, inflating resource and backup costs. Data management system options might provide a lower-cost storage solution.
+ SAP Documentation: [SAP Document Management](https://help.sap.com/viewer/0f3e26f224d9419688b3d25d7c2e46fe/LATEST/en-US/4af6e75227db9972e10000000a4450e5.html)
+ SAP Documentation: [Search for Certified ILM Solutions](https://www.sap.com/dmc/exp/2013_09_adpd/enEN/#/solutions?search=BC-ILM)