Download SAP PRESS Implementing SAP Business Suite on SAP HANA PDF

TitleSAP PRESS Implementing SAP Business Suite on SAP HANA
File Size5.5 MB
Total Pages34
Document Text Contents
Page 1


Reading Sample
This sample chapter describes the infrastructure requirements to prepare your

system landscape for the SAP Business Suite on SAP HANA migration. It covers

multiple methods for ensuring your environment is sized properly, and demonstra-

tes some of the backup and recovery options available to you.

Michael Pytel

Implementing SAP Business Suite on
597 Pages, 2016, $79.95/€79.95
ISBN 978-1-4932-1257-6

First-hand knowledge.

“Infrastructure Planning”



The Author

© 2016 by Rheinwerk Publishing, Inc. This reading sample may be distributed free of charge. In no way must the file be altered, or
individual pages be removed. The use for any commercial purpose other than promoting the book is strictly prohibited.

Page 2


Chapter 3

Running SAP Business Suite on SAP HANA requires infrastructure
changes to your SAP landscape because new software components and
hardware are installed within your landscape. In addition to ensuring
that it’s sized appropriately, you need to ensure that it’s all backed up
and recoverable.

3 Infrastructure Planning

Now that we’ve defined the project scope, you can focus on the decisions you’ll
need to make about your infrastructure planning. For those customers whose SAP
systems began as SAP NetWeaver 7.31 or above, minimal changes are required.
For those customers whose SAP ERP systems were initially installed with SAP R/3
or SAP ERP 6.0 on SAP NetWeaver 7.0 and then upgraded over the years, you’ll
have some more decisions to make. You’ll learn more about why SAP is recom-
mending changes to the primary application server (PAS) and how to comply
with those recommendations. What is an enqueue server, and why does SAP
want it separate? We’ll cover this topic and talk about how it affects sizing. Addi-
tionally, if you were a customer who installed a Java stack in addition to the ABAP
stack during your initial deployment of SAP ERP 6.0, we’ll highlight some of the
changes required in your landscape before the migration to SAP Business Suite on
SAP HANA. SAP doesn’t support the migration of a dual stack system to SAP
HANA. We’ll cover the how and the why as it relates to your SAP Business Suite
on SAP HANA migration.

Sizing your SAP Business Suite on SAP HANA environment will depend on the
scope you identified in Chapter 2 and the architecture your team plans to deploy.
In Chapter 1, you learned about some of the architecture options when running
SAP Business Suite on SAP HANA, which we’ll expand upon in this chapter by
explaining how each architecture option impacts your sizing requirement. SAP
supports running the ABAP PAS on the same hardware as the SAP HANA data-
base, which was previously not an option. We’ll break down the additive sizing
requirements and discuss the potential benefits of this landscape to those custom-
ers with small- to medium-sized environments.

Page 17

Infrastructure Planning3


sizing with SAP S/4HANA Finance, Logistics Execution, Product Dev & Exe-
cution, and Sales & Service.

Figure 3.33 Example User-Based Sizing for SAP Business Suite on SAP HANA

9. In Figure 3.33, you can see that we entered a total of 100 Logistics users, with
a data retention of 84 months for this example. We entered similar data for the
other SAP ERP components to simulate a sizing for a system with 600 active

10. Click on Calculate result at the top of the screen to see a summary of the siz-
ing (see Figure 3.34).

In Figure 3.34, we used the default of 220 workdays per year, with the average
workday running from 9AM to 6PM, and peak load occurring from 9AM to
11AM and 1PM to 2PM. Based on the 600 users we entered, with a retention
period of 84 months for SAP ERP, the Quick Sizer believes we’ll need a SAP
HANA appliance with essentially 1TB of capacity to support both our user load
and data volumes. We also get a SAPS number for the application server in the
sizing summary. The Quick Sizer doesn’t know if our ABAP AS will be on the
same hardware as SAP HANA or separate. We would add these values together if
they will be installed on the same host.

Sizing 3.3


Figure 3.34 Example Sizing Results Displayed

Sizing your new SAP Business Suite on SAP HANA system using the Quick Sizer
can get very complicated if you move into the throughput-based sizing method.
Using this sizing method, you need to capture or estimate specific activity within
your SAP ERP system. If you believe you require this level of sizing, we recom-
mend engaging a certified SAP sizing professional either through SAP or one of its
certified partners.

Page 18


Infrastructure Planning3


In this section, we described how to perform initial sizing estimations, how to
execute the ABAP report for SAP Business Suite on SAP HANA sizing, and how to
perform the user-based sizing method using the Quick Sizer. SAP and its certified
hardware partners are available to support your organization through this pro-
cess. Uncertainty as to what hardware you need to migrate SAP Business Suite on
SAP HANA can be easily remedied by using the solutions described in this chap-
ter and engaging your hardware partner early in the process. SAP sizing tools
exist to ensure success at your go-live. This isn’t a process you’ll only execute
once during the project. As you continue to learn during the upgrade and migra-
tion process, you’ll need to add reminders throughout your project to revalidate
the sizing that was completed. And, don’t forget, you can mitigate risk due to a
bad sizing by running a performance test during your project.


For even more information on SAP sizing, training events, and how-to guides, see the
SAP Service Marketplace at Click on the SAP HANA Quick
Sizer link to access the SAP Business Suite on SAP HANA sizing tool.

3.4 Backup and Recovery

When SAP HANA was initially released and touted as an in-memory database, the
IT person in all of us wondered how data in-memory is handled when the system
crashes. Rest assured, SAP thought of this well before releasing SAP HANA to the
public. SAP HANA is an in-memory database that also uses persistent storage.
This allows you to backup and recover the database just like any other database
on the market. You have graphical, command-line, and third-party backup tools
that enable you to recover when the power is cut, a disk drive fails, or an entire
data center has a catastrophe. Both data and log backups are completed online,
with negligible impact to the users. Parameters in SAP HANA are set by default,
but customers can change these to determine their own recovery point objective
(RPO). Focusing on your SAP Business Suite on SAP HANA migration project,
we’ll cover the backup and recovery scenarios that are specific to a scale-up sce-
nario or a single node. SAP Business Suite on SAP HANA isn’t yet supported on a
scale-out scenario, so we’ll avoid the backup and recovery options for a multi-
node environment. We’ll also point out where you can enable third-party backup

Backup and Recovery 3.4


options, but we won’t cover those vendor tools specifically. The concepts we’ll
cover apply to both SAP HANA-provided tools and third-party tools.


Want to know more about available third-party certified backup options? Go to http://, and enter “hana-
brint” into the search box. A list of currently certified partners will be displayed.

3.4.1 Backups

Your organization’s backup strategy will be a combination of SAP recommenda-
tions, industry best practices, and lessons learned from operating an SAP ERP sys-
tem in your environment. SAP supports data backups, storage snapshots, and log
backups. These backups can be used to recover the system in the event of failure
to the most recent point in time or a specific point in time, or they can be used as
the source for a system copy. The backup and recovery function will be per-
formed and set up by your SAP NetWeaver (Basis) administrators in coordination
with the infrastructure team that supports the backup devices and storage solu-
tions (ideally, the SAP NetWeaver administrator attended the HA200 class we
talked about earlier). SAP recommends a backup strategy that leverages all types
of backups available, specifically, a daily storage snapshot, automatic log backups,
and a complete data backup once a week. In the event of a failure during the
week, you can either restore from the nightly storage snapshot or from the com-
plete data backup, and then read the logs from the automatic log backup. If you
have a failure in your storage solution, the storage snapshot won’t be available,
but the complete data backup will be because you would have saved it to a loca-
tion other than the local SAP HANA system. Leveraging all backup types mitigates
risk and dependencies on a single component of the backup solution.

As you dig into the administration, backup, and recovery of SAP HANA, you’ll see
references to the savepoint. As we mentioned, SAP HANA persists data on disk.
During normal operations, changed data is automatically saved from memory to
disk at regular savepoints. The time period for the savepoint is set by default to
every five minutes, but this value can be changed. So, every five minutes, the
savepoint is defined, and data is written to disk. If you think about a system
restart, the savepoint reduces the time to restart because it doesn’t have to read all
redo log files. Only those redo logs that occurred after the most recent savepoint

Page 33



Transaction (Cont.)
KEPM, 511
LMDB, 194, 202
MB51, 512
MB52, 512
MB5L, 512
MIDO, 512
MIGO, 512
MIRO, 512
MMBE, 512
RSA7, 318
RZ10, 296
RZ70, 304
SA38, 303, 312
SAT, 502
SCI, 486, 492
SE11, 304, 550
SE14, 304, 318
SE16, 53, 507
SE38, 424
SE80, 424
SFW5, 42, 513
SGEN, 303, 586
SICK, 296
SM_WORKCENTER, 72, 89, 191, 393
SM13, 286, 288, 317
SM36, 299
SM37, 58, 322, 514
SM63, 287, 318
SMGW, 316
SMICM, 128
SNOTE, 312
SOLAR01, 86, 378
SOLMAN_SETUP, 190, 379, 453
SPAU, 65, 282, 293
SPDD, 65, 282
SPRO, 410, 525
SQLM, 503
ST03N, 145, 496, 512
ST04, 168, 179
ST05, 502
ST12, 502
STAD, 499
STMS, 301
SU10, 320

Transaction (Cont.)
SWLT, 504
V23, 516
VA01, 374, 378
VA05, 516
VA15, 516
VA25, 516
VA45, 516
VF05, 516
VF31, 516

Transparent tables, 312
Transport, 393, 422–423, 426, 482
Transport Management System (TMS), 301,

365, 420
Troubleshooting, 366, 434, 465
Two-factor authentication, 167


Unicode, 52, 54, 309, 586
status, 52

Universal Journal, 522
Universal Journal � ACDOCA, 522
Unprocessed updates, 317
Upgrade Dependency Analyzer (UDA), 59–60,

Uptime, 586
Usage and Procedure Logging (UPL), 91, 378,

385, 390
data collection, 390
extraction, 386
extractors, 388

Usage rights, 378
User Acceptance Test (UAT), 167, 172, 174
User interface enhancements, 505
User Management Engine (UME), 125, 586
User-based sizing, 148


Value Help views, 547
Virtual memory, 31

Page 34

First-hand knowledge.

We hope you have enjoyed this reading sample. You may recommend
or pass it on to others, but only in its entirety, including all pages. This
reading sample and all its parts are protected by copyright law. All usage
and exploitation rights are reserved by the author and the publisher.

Michael Pytel is currently the chief innovation officer
and co-founder of NIMBL, an SAP implementations
consulting firm. He has more than 14 years of hands-
on technical experience with SAP solutions, including

Michael Pytel

Implementing SAP Business Suite on
597 Pages, 2016, $79.95/€79.95
ISBN 978-1-4932-1257-6
© 2016 by Rheinwerk Publishing, Inc. This reading sample may be distributed free of charge. In no way must the file be alte-
red, or individual pages be removed. The use for any commercial purpose other than promoting the book is strictly prohibited.

Similer Documents