This Blog was made to help customers prepare the SAP S/4HANA landscape conversion considering the sizing relevant KPI’s for the key performance indicators.
There are many perspectives that we need to consider when doing this planning. The sizing procedure helps customers to determine the correct resources required by an application within customer’s business context.
From the customer perspective, sizing is the translation of business requirements into hardware requirements, but from the development point of view, sizing refers to the creation of a sizing model for the product functionality with a reasonable number of input parameters and assumptions.
Considering this behavior can be changed during project, we cannot forget to re-visit this planning if any change is made on landscape requirements even from customer or development point of view, this can change the actual requirements and impact on overall solution performance.
Also, depending on the scope, this may also include a detailed analysis of the systems to be migrated and/or verification of the sizing assumptions made on-premise or cloud.
What you must know ?
Your business decisions will lead you to the sizing, but it’s not easy to translate it into the sizing forms, and even be sure everything was covered, that’s why you have to understand every business requirement, peak times, user behavior, number of transactions executed by them and most important of all, re-visit this requirements at every decision project step.
All your interpretations and decisions related to the business requirements must be made accordingly.
When you start sizing a conversion to SAP S/4HANA, you must make sure that all relevant actions related to the system housekeeping like, regular jobs, data management and archiving, deletion of unnecessary clients, deletion of unnecessary data (basis tables and application logs), custom code decommissioning, including not in use Z tables, and every item that can help you reduce your actual database size was completed or evaluated in advance.
What are the risks when sizing a project?
Sizing is not the way customer configure the system, actual system configuration is a task performed by the hardware vendor who must ensure the system landscape meets the hardware requirements determined by sizing.
The best sizing is related to the ability to have not only a scalable hardware, but also a scalable application software.
The best evaluation will be confirmed with a good test of system transaction volume, so a stress test must be planned to confirm that all decisions were made in the right way, but if not, the way infrastructure was organized must allows to make it scalable.
Those are the main risks you have to mitigate when evaluating data to run the sizing:
Incomplete input data
◉ Challenge to obtain sufficient usage information as sizing input
◉ Often caused by communication issues
◉ Insufficient sizing input is compensated by assumptions, which should be documented
Assumptions are not verified
◉ While is perfect ok to work with assumption you must ensure that a verification process is included in the project plan
Custom coding @ Special data constellations
◉ Are very hard to predict, make sure there is a verification process
◉ Make sizing measurements
Running Sizing Report
This report runs on SAP_BASIS 620 and higher, it is suitable for sizing all business suite products (ERP, CRM, SRM, SCM, etc…), but it’s nor suitable for BW, in this case, please refer to SAP Note 2296290 – New Sizing Report for SAP BW/4HANA
◉ The report /SDF/HDB_SIZING is described in SAP Note 1872170 – ABAP on HANA sizing report (S/4HANA, Suite on HANA…)
◉ Used for source ERP 6.0 EhPx, SoH, or S/4HANA Simple Finance 1503
◉ With ST-PI 2008_1_[700-710] SP 09 or ST-PI 740 SP00 and higher, you install report /SDF/HDB_SIZING’s latest version by implementing Note using SAP Note 2303847
This report will consider the SAP S/4HANA data model changes, also estimates the maximum memory consumption of the database, considers distribution of tables to row and column store, considers differences for secondary indexes, compression of legacy database and data aging for technical objects.
The sizing report can also be evaluated by running the Readiness Check:
On the SAP S/4HANA Sizing Simulation tab, the initial target SAP S/4HANA size is provided. It is based on the ABAP on SAP HANA sizing report for SAP Business Suite powered by SAP HANA and SAP S/4HANA, which calculates the initial memory requirements for the SAP HANA database based on current data volumes. These requirements were derived from the size of the tables and the compression rate in the source system. With the identified initial target SAP S/4HANA size, you can perform a target system sizing simulation by manually adding additional factors (future database growth, data volume reduction in your SAP ERP system, as well as additional growth arising from new functionalities, mergers, and acquisitions).
On the SAP S/4HANA Sizing tab, your estimated initial target system size is displayed in more detail, providing more information about the estimated memory and disk size requirements by category. In addition, you can see the top 20 database tables of your source system.
On the Data Volume Management tab, the size of your archiving potential in GB and percentage measurements by document type are provided, based on the top database tables in the past 12 and 24 months. In the bar chart view, the chart on the left shows how many gigabytes can be archived for each document type in relation to its total size in your source system. The chart on the right shows the corresponding archiving potential as a percentage for each document type. The bar charts show up to ten document types. To see the analyzed objects, switch to the table view.
How to evaluate the sizing report results ?
The sizing report includes the sizing projections, based on the actual table sizes in the legacy system as well as an estimation of how much the memory footprint can be reduced using functionalities that SAP HANA will enable
◉ Column store and row store estimations have good enough accuracy (10-20%). Still, do not forget it is an estimation.
◉ Work Space (temporary memory) estimation uses a simple formula (data size in memory) * 2. Based on experiences, if the work space is bigger than 3TB, it might be oversized.
◉ Always check the top tables. Very often, you will find basis tables with deletion / archiving potential such as iDoc, workflow, application log tables, etc.
◉ The total estimated memory requirement given by the report should not be considered as the final memory sizing result. Take into account that:
◉ Not all the server physical memory will be available to SAP HANA (OS and other processes are run too).
◉ There should be enough space left for future data growth or functional extension
The sizing report takes a snapshot, any growth between that date and the go-live date should be considered.
Activities recommended on transition preparation
There are some activities and decisions that might drive you doing the sizing, some transition preparation activities will help.
Hana Partitioning: Check the sizing report outcome to evaluate the tables with more than 2,000,000,000 records.
Archive before sizing: Before performing the S/4HANA sizing and executing the conversion, it is important analyse all data that can be archived, or which does not have to be in the business system anymore
◉ Archived data is still available, typically through additional tooling
◉ SAP strongly recommends that you archive as much data as possible from the source database before you convert to SAP S/4HANA. This will reduce your conversion and downtime
◉ There needs to be a housekeeping strategy to deal with data included in technical tables, which has become outdated and unnecessary
◉ In order to deal with those tables, you can leverage the sizing report attached to SAP Note 1872170 to identify the top technical tables and afterwards SAP Note 2388483 for instructions on how to delete data.
Define UX strategy: Do not forget the end user interface strategy to define the kind of access users will have.
It is necessary to add the resource for Fiori Frontend Server (FES) in addition in case FES is embedded in S/4HANA Backend Server. It can be estimated with Quick Sizer
Tip: Considering total user number is 1000 and half of them (500) login the system in a peak hour (9:00~10:00), you have to add the number of users at peak time, so, add the Input “500” in “No. of concurrent users”. Also adjust the start and end peak time for an accurate evaluation.
Embedded Analytics strategy: When using this feature, It is necessary to add the resource for embedded analytics in addition, which can be estimated with Quick Sizer too.
Tip: At this case the total user number is 1000 and half of them (500) login the system in a peak hour (9:00~10:00), user run and navigate report 5 times in average in the peak hour and they run 50% light query and 50% medium query. Here the input “500” in “No. of concurrent users”.
The figures to input heavily depends on the analytics scenario, so it is recommended to ask analytics experts to understand each parameter value and set the appropriate values based on the analytic scenario the customer assume.
e.g. Fiori Launchpad for average user has 10 tiles including number and login user in peak hour is 500, at least 5000 (10*500) queries are executed in the peak hour. (if not using cache).
Queries are expected to be tuned enough. The longer the runtime is, more H/W resource is consumed.
Advanced Sizing Service from SAP: Advanced Sizing sharpens the initial sizing performed in the planning phase. Depending on the scope, this may also include a detailed analysis of the systems to be migrated and / or the verification of the sizing assumptions made.
With this service customer will be supported in filling out the sizing questionnaire, some additional questions from the customer can be answered, ask SAP for guidance.
Action to closure
This is not an easy work to run an accurate Sizing project, this can only be done with the participation of all involved parts, from technical to functional team, you can start work running this activities
◉ Use Readiness Check to help with the initial evaluation
◉ If necessary, run Advanced Sizing service from SAP
◉ Start a QuickSizer project for SAP S/4HANA
◉ Ask technical and functional team to help fill the QuickSizer questionnaire
◉ Wrap your hardware partner on planning
◉ Re-visit sizing when a project decision can impact results
No comments:
Post a Comment