Introducing the new SAP HANA capture and replay tool, available with SAP HANA SPS12
Testing challenges
Testing application workload can be a huge effort for users, developers and consultants alike. Also, things do not get easier on a large scale, especially for moving from one revision or SPS of SAP HANA to another.
The common approach to this is using customized scripts for database access or executing test scenarios in client applications. Of course, developing such scenarios and test cases is a large and therefore very costly development effort – all of it just to ensure the solution still works correctly with the new SAP HANA software.
For regression testing a new SAP HANA SPS across a whole system landscape with multiple application stacks the complexity increases even more since now the interoperation between SAP HANA and the various client applications or reporting tools needs to be tested. The outcome of all this effort are hand-crafted tests that may only resemble the actual workload to a certain degree.
Recording workload instead of “developing” it
For this reason, we are offering the new SAP HANA capture and replay tool with SAP HANA SPS12. Specifically aimed at the aforementioned testing scenarios that many of us run into every day, SAP HANA capture and replay offers a currently semi-automated tool for integrated testing in the context of SAP HANA. The goal is simplifying the manual effort needed for creating tests and performing a more accurate replay than what is possible with other approaches.
SAP HANA capture and replay allows for similar concurrency, memory allocation and CPU usage than the captured workload, something that is difficult to achieve with for example script-based testing scenarios.
Simple steps instead of coding tests
The process is very simple:
- Simply generate workload on the database using the existing landscape and record it using the new tool (1).
For initializing a consistent test system, a full database backup is also needed. - Next, use the tool to pre-process the workload and prepare it for replay on your desired SAP HANA test system (2).
- Then, simply trigger the replay (3) and
- use the report for analyzing any runtime-based differences between the capture and the replay (4).
In this initial release, SAP HANA Capture and Replay can capture all incoming SQL statements at the session layer of the SAP HANA database. This covers all connections via ODBC, JDBC or SQLDBC (SAP NetWeaver).
However, it is currently not possible to capture XS engine workload coming to the database via HTTP calls. This includes statements coming from native HANA XS Classic applications (not XS Advanced) as well as statements coming directly from SAP Analysis for Office 2.x.
One tool, many uses
The use cases for SAP HANA capture and replay are very diverse. The tool can be used to
- evaluate potential regressions and improvements across SAP HANA revisions, O/S software updates, firmware changes, etc.
- evaluate performance impact of changed information model implementations, system landscape setups (e.g. adding/removing SAP HANA nodes), etc.
- test different table distributions, index changes, partition changes, etc.
- analyze impact of changes to system parameters or data volume changes.
BETA program for the early birds
Beginning with SAPPHIRE 2016, SAP also offers a invitation-only beta program for our new Hybrid Cloud Service program for SAP HANA capture and replay.
If you or your customers want to register and are interested in participating, please refer to the following links:
|
|
 |
Other useful links
Here is a collection of other useful links with information related to SAP HANA capture and replay:
Hi Lucas,
For initializing a consistent test system, a full database backup is also needed.
I've played around the capturing and replaying feature in SPS12. But Instead of doing a system copy, why not SAP provide the functionality by just exporting the "captured process" and import and "replay" it to the test system for analysis?
hopefully this feature will introduce in next release, where it offers flexibility and also allow customer to export the workload and send to SAP for ease analysis.
Just my 2 cents worth.
Cheers,
Nicholas Chang
Out of interest: how would that work? How would you be able to replay a workload that might include data changes on a different system without making sure beforehand that the system has the same data than the source?
I'm thinking about different join set sizes, different table extensions, maybe different additional application's data in the same instance etc. here.
What worth is a replay if the queries all of a sudden run much faster, because the replay system barely contains any actual data?
System performance in databases is dependent on the volume, variety and velocity of data. For a test to have any meaningful outcome, one needs to understand what parameter was changed. The moment the base data is a lot different, this becomes quite hard to do.
Besides: so far I've not seen that anything prevents you from replaying a workload capture on the instance of your choice (even the source instance).
Hi Lars,
Thanks for the informative head up. 😉 Always appreciate.
Just my thought, by having the features of exported & imported captured data, thus save the effort of doing a system copy on source instance with data captured to target, however, allowing us to simply import the captured data and replay it on Q, sandbox system anytime, which can be similar or close to source db.
although we couldn't get the accurate runtime result due to the variation of data, but at least it gives us an overview and allow us to understand what's the impact/changes to run on different revision, parameters and etc as first hand info.
Cheers,
Nicholas Chang
And you can do that.
The recommendation to replay workloads on a copy of the original instance is there, to allow for performance numbers, that you actually can compare.
What do you do with the gut feeling/overview from the Q-system if you can neither use it to assert that there are no problems nor to understand the nature of problems should you find any?
I think that it is a common mistake to use the usually stripped down Q system to evaluate productions system performance. And the recommendation given in this document is there to help everyone avoid that mistake.
Hi Nicolas,
thanks for your feedback. Maybe to add just a few things to Lars' comments:
1.) As Lars stated, it's a recommendation to use a copy of the source system, no one will force you to. In order to get results you can use for further evaluation of potential issues and performance impacts, you should do so though.
2.) We are thinking about simplifying the backup step within the capture step to make it a little easier from a process perspective. Potentially, we are also looking into working with only changed tables, in order to minimize the size of data that needs to be moved. Of course, none of this is confirmed yet.
Regards
Lucas
Hi Lucas,
The Capture and Replay delivery unit seems to be missing from Software Downloads? I can see all the other components so not sure if this is an Authorisation/Licence issue?
Thanks
Kris
Hi Kris,
I was dealing with the same issue. I could locate the Delivery Unit HANA_REPLAY.tgz in the HANA CD bundle of SPS 12. Simply searching for the number 51050846 leads you to the three HANA CDs. After extracting it is included in the folder "HCO_HANA_WORKLOAD_REPLAY_10_SP" as a ZIP file:
Best
Sebastian
Hi Kris,
thanks for the feedback. I just checked and was able to find it using my internal SMP user.
If the problem persists, please let me know and I will try to find out why the DU isn't showing up for your user in SMP.
Regards
Lucas
Hi Lucas,
Still cant see the DU under Support Packages and Patches. I will send the relevant S user to your SAP email address.
Thanks
Kris