Sg 248086

8/9/2019 Sg 248086

1/266

Front cover

In-memory Computingwith SAP HANA on LenovoX6 Systems

Introduces System x solution for SAP

HANA

Describes SAP HANA features and

use cases

Describes operational aspects for

SAP HANA

Describes SAP HANA high availablity

and disater recovery scenarios

Martin Bachmaier

Ilya Krutov

8/9/2019 Sg 248086

2/266

8/9/2019 Sg 248086

3/266

8/9/2019 Sg 248086

4/266

© Copyright Lenovo 2015. All rights reserved.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule

Contract

Last update on May 2015

This edition applies to Lenovo X6 rack servers and Flex System X6 compute nodes

Note: Before using this information and the product it supports, read the information in “Notices” onpage vii.

8/9/2019 Sg 248086

5/266

© Copyright IBM Corp. 2015. All rights reserved.iii

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Authors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Chapter 1. Basic concepts of in-memory computing . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Keeping data in-memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.1 Using main memory as the data store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.2 Data persistence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Minimizing data movement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1 Compression. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.2 Columnar storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.3 Pushing application logic to the database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3 Dividing and conquering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3.1 Parallelization on multi-core systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.3.2 Data partitioning and scale-out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Chapter 2. SAP HANA overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1 SAP HANA overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.1 SAP HANA architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.2 SAP HANA appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 SAP HANA delivery model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.1 SAP HANA as an appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.2 SAP HANA tailored data center integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 Sizing SAP HANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.1 Memory per core ratio for SAP HANA appliances . . . . . . . . . . . . . . . . . . . . . . . . 152.3.2 Sizing approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4 SAP HANA software licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Chapter 3. Software components and data replication methods . . . . . . . . . . . . . . . . . 19

3.1 SAP HANA software components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.1 SAP HANA database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.2 SAP HANA client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.3 SAP HANA studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1.4 SAP HANA studio repository. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.5 SAP HANA landscape management structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.6 SAP host agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1.7 SAP HANA Lifecycle Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1.8 SAP HANA Lifecycle Management tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.1.9 Solution Manager Diagnostics agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2 Data replication methods for SAP HANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2.1 Trigger-based replication with SAP Landscape Transformation. . . . . . . . . . . . . . 30

3.2.2 ETL-based replication with SAP BusinessObjects Data Services . . . . . . . . . . . . 31

3.2.3 Extractor-based replication with Direct Extractor Connection. . . . . . . . . . . . . . . . 31

3.2.4 Log-based replication with Sybase Replication Server. . . . . . . . . . . . . . . . . . . . . 32

3.2.5 Comparing the replication methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Chapter 4. SAP HANA integration scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

8/9/2019 Sg 248086

6/266

iv SAP HANA on Lenovo X6 Systems

4.1 Basic use case scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2 SAP HANA as a technology platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2.1 SAP HANA data acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2.2 SAP HANA as a source for other applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.3 SAP HANA for operational reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.4 SAP HANA as an accelerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.5 SAP products that are running on SAP HANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.5.1 SAP NetWeaver Business Warehouse that is powered by SAP HANA . . . . . . . . 45

4.5.2 Migrating SAP NetWeaver Business Warehouse to SAP HANA . . . . . . . . . . . . . 49

4.5.3 SAP Business Suite that is powered by SAP HANA. . . . . . . . . . . . . . . . . . . . . . . 53

4.6 Programming techniques that use SAP HANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Chapter 5. Lenovo System x solutions for SAP HANA . . . . . . . . . . . . . . . . . . . . . . . . . 575.1 eX5 systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.1.1 x3850 X5 and x3950 X5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.1.2 x3690 X5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.1.3 Intel Xeon processor E7 family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.1.4 Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.1.5 Flash technology storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.1.6 x3950 X5 Workload Optimized Solution for SAP HANA. . . . . . . . . . . . . . . . . . . . 67


5.2 Lenovo X6 systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.2.1 Intel Xeon processor E7 v2 family. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76


5.2.3 Memory (DDR3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.2.4 Flash technology storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82



5.3 Flex System X6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.3.1 Scalability and QPI connectivity of the x880 X6 Compute Node. . . . . . . . . . . . . . 96


5.3.3 Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.3.4 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

5.3.5 Flex System x880 X6 solution for SAP HANA . . . . . . . . . . . . . . . . . . . . . . . . . . 102

5.4 IBM General Parallel File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

5.4.1 Common GPFS features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

5.4.2 GPFS extensions for shared-nothing architectures . . . . . . . . . . . . . . . . . . . . . . 108

5.4.3 Scaling-out SAP HANA that uses GPFS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

5.4.4 System x GPFS Storage Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

5.5 Networking options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

5.5.1 RackSwitch G8264 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

5.5.2 RackSwitch G8124E. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

5.5.3 RackSwitch G8052 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Chapter 6. SAP HANA IT landscapes with System x solutions . . . . . . . . . . . . . . . . . 1256.1 eX5 based environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

6.1.1 Single-node eX5 solution for Business Warehouse . . . . . . . . . . . . . . . . . . . . . . 128

6.1.2 Single-node eX5 solution for SAP Business Suite on HANA . . . . . . . . . . . . . . . 129

6.1.3 Scale-out eX5 solution for Business Warehouse . . . . . . . . . . . . . . . . . . . . . . . . 132

6.2 X6 based environments that use Intel Xeon E7 v2 processors. . . . . . . . . . . . . . . . . . 134

6.2.1 Single-node X6 solution for Business Warehouse . . . . . . . . . . . . . . . . . . . . . . . 137

6.2.2 Single-node X6 solution for SAP Business Suite on HANA . . . . . . . . . . . . . . . . 140

6.2.3 Scale-out X6 solution for Business Warehouse . . . . . . . . . . . . . . . . . . . . . . . . . 143

8/9/2019 Sg 248086

7/266

Contentsv

6.3 Lenovo X6 based environments that use Intel Xeon E7 v3 processors . . . . . . . . . . . 146

6.3.1 Single-node X6 solution for Business Warehouse . . . . . . . . . . . . . . . . . . . . . . . 150

6.3.2 Single-node X6 solution for SAP Business Suite on HANA . . . . . . . . . . . . . . . . 153

6.3.3 Scale-out X6 solution for Business Warehouse . . . . . . . . . . . . . . . . . . . . . . . . . 157

6.4 Upgrading X6 from Intel Xeon E7 v2 to E7 v3 CPUs . . . . . . . . . . . . . . . . . . . . . . . . . 160

6.4.1 Upgrading a single node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

6.4.2 Converting a single node into a scale-out environment . . . . . . . . . . . . . . . . . . . 1606.4.3 Upgrading a scale-out environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

6.5 Flex System X6 based environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

6.5.1 Single-node x880 X6 solution for Business Warehouse . . . . . . . . . . . . . . . . . . . 163

6.5.2 Single-node x880 X6 solution for SAP Business Suite on HANA. . . . . . . . . . . . 166

6.5.3 Scale-out x880 X6 solution for Business Warehouse . . . . . . . . . . . . . . . . . . . . . 168

6.6 Migrating from eX5 to X6 servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

6.6.1 Disruptive migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

6.6.2 Hybrid SAP HANA cluster with eX5 and X6 nodes. . . . . . . . . . . . . . . . . . . . . . . 171

6.7 SAP HANA on VMware vSphere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

6.7.1 vSphere on eX5 workload-optimized models for SAP HANA . . . . . . . . . . . . . . . 174

6.7.2 vSphere on rack-mount X6 workload-optimized models for SAP HANA . . . . . . 175

6.7.3 VMware vSphere licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1756.8 Sharing an SAP HANA system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

6.9 Security and encryption of an SAP HANA system . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

6.9.1 Encrypting SAP HANA data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

6.9.2 Securing SAP HANA communication channels . . . . . . . . . . . . . . . . . . . . . . . . . 181

6.9.3 Securing SAP HANA access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

6.10 Large-scale deployments of Lenovo System x solutions . . . . . . . . . . . . . . . . . . . . . 182

Chapter 7. Business continuity and resiliency for SAP HANA . . . . . . . . . . . . . . . . . . 1877.1 Overview of business continuity options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

7.1.1 GPFS based storage replication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

7.1.2 SAP HANA System Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

7.1.3 Special considerations for DR and long-distance HA setups . . . . . . . . . . . . . . . 194

7.2 HA and DR for single-node SAP HANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1947.2.1 High availability (by using GPFS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

7.2.2 Stretched high availability (by using GPFS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

7.2.3 Disaster recovery (by using GPFS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

7.2.4 Disaster recovery (by using SAP HANA System Replication) . . . . . . . . . . . . . . 205

7.2.5 HA plus DR (by using GPFS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

7.2.6 HA (by using GPFS) plus DR (by using SSR). . . . . . . . . . . . . . . . . . . . . . . . . . . 208

7.3 HA and DR for scale-out SAP HANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

7.3.1 HA by using GPFS storage replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

7.3.2 DR by using GPFS storage replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

7.3.3 HA by using GPFS replication plus DR by using SAP HANA Replication . . . . . 221

7.4 HA and DR for SAP HANA on Flex System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

7.5 Backup and restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2247.5.1 Basic operating system backup and recovery. . . . . . . . . . . . . . . . . . . . . . . . . . . 224

7.5.2 Basic database backup and recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

7.5.3 File-based backup tool integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

7.5.4 Database backups by using GPFS snapshots . . . . . . . . . . . . . . . . . . . . . . . . . . 227

7.5.5 Backup tool integration with Backint for SAP HANA. . . . . . . . . . . . . . . . . . . . . . 227

7.5.6 Tivoli Storage Manager for ERP 6.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

7.5.7 Symantec NetBackup 7.5 for SAP HANA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

7.5.8 Backup and restore as a DR strategy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

8/9/2019 Sg 248086

8/266

vi SAP HANA on Lenovo X6 Systems

Chapter 8. SAP HANA operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

8.1 Installation services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

8.2 Lenovo SAP HANA Operations Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

8.3 Interoperability with other platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

8.4 Monitoring SAP HANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

8.5 Installing more agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

8.6 Software and firmware levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2358.7 Support process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

8.7.1 Lenovo and SAP-integrated support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

8.7.2 Lenovo SAP Center of Competence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Appendix A. Additional topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

A.1 GPFS license information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

A.2 File-based backup with IBM Tivoli Storage Manager for ERP . . . . . . . . . . . . . . . . . . 241

A.2.1 Setting up Data Protection for SAP HANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

A.2.2 Backing up the SAP HANA database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

A.2.3 Restoring the SAP HANA database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Lenovo Press publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Help from Lenovo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

8/9/2019 Sg 248086

9/266

© Copyright Lenovo 2015. All rights reserved.vii

Notices

Lenovo may not offer the products, services, or features discussed in this document in all countries. Consultyour local Lenovo representative for information on the products and services currently available in yourarea.Any reference to a Lenovo product, program, or service is not intended to state or imply that only that Lenovoproduct, program, or service may be used. Any functionally equivalent product, program, or service that doesnot infringe any Lenovo intellectual property right may be used instead. However, it is the user's responsibilityto evaluate and verify the operation of any other product, program, or service.

Lenovo may have patents or pending patent applications covering subject matter described in this document.The furnishing of this document does not give you any license to these patents. You can send licenseinquiries, in writing, to:

Lenovo (United States), Inc.1009 Think Place - Building OneMorrisville, NC 27560U.S.A.Attention: Lenovo Director of Licensing

LENOVO PROVIDES THIS PUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHEREXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OFNON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some

jurisdictions do not allow disclaimer of express or implied warranties in certain transactions, therefore, thisstatement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically madeto the information herein; these changes will be incorporated in new editions of the publication. Lenovo maymake improvements and/or changes in the product(s) and/or the program(s) described in this publication atany time without notice.

The products described in this document are not intended for use in implantation or other life supportapplications where malfunction may result in injury or death to persons. The information contained in thisdocument does not affect or change Lenovo product specifications or warranties. Nothing in this documentshall operate as an express or implied license or indemnity under the intellectual property rights of Lenovo or

third parties. All information contained in this document was obtained in specific environments and ispresented as an illustration. The result obtained in other operating environments may vary.

Lenovo may use or distribute any of the information you supply in any way it believes appropriate withoutincurring any obligation to you.

Any references in this publication to non-Lenovo Web sites are provided for convenience only and do not inany manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of thematerials for this Lenovo product, and use of those Web sites is at your own risk.

Any performance data contained herein was determined in a controlled environment. Therefore, the resultobtained in other operating environments may vary significantly. Some measurements may have been madeon development-level systems and there is no guarantee that these measurements will be the same ongenerally available systems. Furthermore, some measurements may have been estimated throughextrapolation. Actual results may vary. Users of this document should verify the applicable data for their

specific environment.

8/9/2019 Sg 248086

10/266

viii SAP HANA on Lenovo X6 Systems

Trademarks

Lenovo, the Lenovo logo, and For Those Who Do are trademarks or registered trademarks of Lenovo in theUnited States, other countries, or both. These and other Lenovo trademarked terms are marked on their firstoccurrence in this information with the appropriate symbol (® or ™), indicating US registered or common lawtrademarks owned by Lenovo at the time this information was published. Such trademarks may also be

registered or common law trademarks in other countries. A current list of Lenovo trademarks is available onthe Web at http://www.lenovo.com/legal/copytrade.html.

The following terms are trademarks of Lenovo in the United States, other countries, or both:

BladeCenter®

eX4™

eX5™

eXFlash™

FlashCache™

Flex System™

Lenovo®

MAX5™

RackSwitch™

Lenovo(logo)®

ServeRAID™

System x®

X5™

The following terms are trademarks of other companies:

Intel, Intel Xeon, Itanium, Intel logo, Intel Inside logo, and Intel Centrino logo are trademarks or registeredtrademarks of Intel Corporation or its subsidiaries in the United States and other countries.

Linux is a trademark of Linus Torvalds in the United States, other countries, or both.

Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States,other countries, or both.

Other company, product, or service names may be trademarks or service marks of others.

http://www.lenovo.com/legal/copytrade.htmlhttp://www.lenovo.com/legal/copytrade.html

8/9/2019 Sg 248086

11/266

© Copyright Lenovo 2015. All rights reserved.ix

Preface

The forth edition of this Lenovo® Press publication describes in-memory computing

appliances from Lenovo and SAP that are based on Lenovo X6 and eX5™ flagship systemsand SAP HANA. It covers the basic principles of in-memory computing, describes the Lenovo

X6 and eX5 hardware offerings, and explains the corresponding SAP HANA IT landscapesthat use these offerings.

This book also describes the architecture and components of the Lenovo System x® solution

for SAP HANA, with IBM General Parallel File System (GPFS) as a cornerstone. Thefollowing SAP HANA operational disciplines are explained: Scalability options, highavailability and disaster recovery, backup and restore, and virtualization possibilities for SAP

HANA appliances.

The following topics also are covered:

Basic principles of in-memory computing

SAP HANA overview

Software components and replication methods

SAP HANA use cases and integration scenarios

The System x solution for SAP HANA

SAP IT landscapes that use the System x solution for SAP HANA

Options for business continuity (high availability, disaster recovery, and backupand restore)

SAP HANA operations

This book is intended for SAP administrators and technical solution architects. It is also for

Lenovo Business Partners and Lenovo employees who want to know more about the SAPHANA offering and other available Lenovo solutions for SAP clients.

Authors

This book was produced by Lenovo Press in collaboration with a team of subject matterexperts from around the world.

Martin Bachmaier is an IT Versatilist in the Lenovo Solutionsdevelopment lab at Stuttgart, Germany. He is a part of the team that

is developing the Lenovo System x solution for SAP HANA. Martin

has an extensive background in designing, implementing, andmanaging scale-out data centers, HPC clusters, cloudenvironments, and high performance storage and archivingsystems. In 2013, he implemented one of Africa's most powerful

computing hubs in IBM's newly opened Research Lab in Nairobi,Kenya. Martin frequently presents university lectures, and holds

credentials in CCNA, CCNA Security, and VMware CertifiedProfessional. He has authored over a dozen books and papers.

8/9/2019 Sg 248086

12/266

x SAP HANA on Lenovo X6 Systems

Thanks to the authors of the previous edition of this book:

Gereon Vey Tomas Krojzl

Thanks to the following people for their contributions to this project:

Irene HopfDr. Oliver RettigTag Robertson

David WattsLenovo

Ilya Krutov is a Project Leader at Lenovo Press in the Lenovo

Enterprise Business Group. He manages and produces pre-saleand post-sale technical publications for various IT topics, including

x86 rack and blade servers, server operating systems and software,virtualization and cloud, and data center networking. Ilya has morethan 15 years of experience in the IT industry, and he performs

various roles, including Team Leader, Portfolio Manager, BrandManager, IT Specialist, and Certified Instructor. He has written

more than 200 books, papers, and other technical documents. Hehas a Bachelor's degree in Computer Engineering from the

Moscow Engineering and Physics Institute (Technical University).

8/9/2019 Sg 248086

13/266

© Copyright Lenovo 2015. All rights reserved.1

Chapter 1. Basic concepts of in-memory

computing

In-memory computing is a technology that allows the processing of massive quantities of datain main memory to provide immediate results from analysis and transaction. The data that is

processed is ideally real-time data (that is, data that is available for processing or analysisimmediately after it is created).

To achieve the preferred performance, in-memory computing adheres to the following basic

concepts:

Keep data in main memory to speed up data access.

Minimize data movement by using the columnar storage concept, compression, andperforming calculations at the database level.

Divide and conquer. Use the multi-core architecture of modern processors and

multi-processor servers (or even scale out into a distributed landscape) to grow beyondwhat can be supplied by a single server.

This chapter describes these basic concepts and provides some examples. It does not

describe the full set of technologies that are used with in-memory databases, such as SAPHANA, but it does provide an overview of how in-memory computing is different from

traditional concepts.

This chapter includes the following topics:

Keeping data in-memory Minimizing data movement Dividing and conquering

1

8/9/2019 Sg 248086

14/266

2 SAP HANA on Lenovo X6 Systems

1.1 Keeping data in-memory

Today, a single enterprise class server can hold several terabytes of main memory. At thesame time, prices for server main memory dramatically dropped over the last few decades.

This increase in capacity and reduction in cost makes it a viable approach to keep hugeamounts of business data in memory. This section describes the benefits and challenges.

1.1.1 Using main memory as the data store

The most obvious reason to use main memory (RAM) as the data store for a database is thataccessing data in main memory is much faster than accessing data on disk. The compared

access times for data in several locations are shown in Figure 1-1.

Figure 1-1 Data access times of various storage types relative to RAM (logarithmic scale)

The main memory is the fastest storage type that can hold a significant amount of data.

Although CPU registers and CPU cache are faster to access, their usage is limited to theactual data processing. Data in main memory can be accessed more than a hundredthousand times faster than data on a spinning hard disk drive (HDD), and even flash

technology storage is approximately a thousand times slower than main memory. Mainmemory is connected directly to the processors through a high-speed bus, and hard disks are

connected through a chain of buses (QPI, PCIe, and SAN) and controllers (I/O hub, RAIDcontroller or SAN adapter, and storage controller).

Compared with keeping data on disk, keeping the data in main memory can improvedatabase performance through the advantage in access time.

Volatile Non-volatile

1,000,000

100,000

10,000

1,000

100

10

1

0,1

0,01

0,001

CPU register CPU Cache RAM SSD/Flash Hard disk

12x

17x

2,000x

150x

8/9/2019 Sg 248086

15/266

Chapter 1. Basic concepts of in-memory computing3

1.1.2 Data persistence

Keeping data in main memory brings up the issue of what happens if there is a loss of power.

In database technology, atomicity, consistency, isolation, and durability (ACID) is the followingset of requirements that ensures that database transactions are processed reliably:

A transaction must be atomic. If part of a transaction fails, the entire transaction must failand leave the database state unchanged.

The consistency of a database must be preserved by the transactions that it performs.

Isolation ensures that no transaction interferes with another transaction.

Durability means that after a transaction is committed, it remains committed.

Although the first three requirements are not affected by the in-memory concept, durability isa requirement that cannot be met by storing data in main memory alone. Main memory is

volatile storage. It loses its content when it is out of electrical power. To make data persistent,it must be on non-volatile storage, such as HDDs, solid-state drives (SSDs), or flash devices.

The storage that is used by a database to store data (in this case, main memory) is divided

into pages. When a transaction changes data, the corresponding pages are marked andwritten to non-volatile storage in regular intervals. In addition, a database log captures all

changes that are made by transactions. Each committed transaction generates a log entrythat is written to non-volatile storage, which ensures that all transactions are permanent.

Figure 1-2 shows this setup by using the example of SAP HANA. SAP HANA stores changedpages in savepoints, which are asynchronously written to persistent storage in regular

intervals (by default, every 5 minutes). The log is written synchronously. A transaction doesnot return before the corresponding log entry is written to persistent storage to meet the

durability requirement.

Figure 1-2 Savepoints and logs in SAP HANA

After a power failure, the database can be restarted much like a disk-based database. Thedatabase pages are restored from the savepoints and then the database logs are applied

(rolled forward) to restore the changes that were not captured in the savepoints. This actionensures that the database can be restored in memory to the same state as before the power

failure.

1.2 Minimizing data movement

The second key to improving data processing performance is to minimize the movement ofdata that is within the database and between the database and the application. This sectiondescribes measures to achieve this state.

Time

Data savepoint

to persistent

storage

Log written

to persistent storage

(committed transactions) Power failure

8/9/2019 Sg 248086

16/266


1.2.1 Compression

Although today’s memory capacities allow keeping enormous amounts of data in-memory,compressing the data in-memory is still preferable. The goal is to compress data in a way thatdoes not use up the performance that is gained while still minimizing data movement from

RAM to the processor.

By working with dictionaries to represent text as integer numbers, the database can

compress data significantly and thus reduce data movement while not imposing more CPUload for decompression; in fact, it can add to the performance, as shown in Figure 1-5 onpage 6. This situation with a simplified example is shown in Figure 1-3.

Figure 1-3 Dictionary compression

The original table is shown on the left side of Figure 1-3, and it contains text attributes (that is,material and customer name) in their original representation. The text attribute values are

stored in a dictionary (upper right), and an integer value is assigned to each distinct attributevalue. In the table, the text is replaced by the corresponding integer value as defined in the

dictionary. The date and time attribute also are converted to an integer representation. Theuse of dictionaries for text attributes reduces the size of the table because each distinctattribute value must be stored only once in the dictionary; therefore, each additional

occurrence in the table must be referred to by the corresponding integer value.

The compression factor that is achieved by this method highly depends on data beingcompressed. Attributes with few distinct values compress well, but attributes with many

distinct values do not benefit as much.

There are other, more effective compression methods that can be used with in-memorycomputing. However, for these methods to be useful, they must have the correct balance

between compression effectiveness, which gives you more data in your memory or less datamovement (that is, higher performance), resources that are needed for decompression, anddata accessibility (that is, how much unrelated data must be decompressed to get to the data

that you need). Dictionary compression combines good compression effectiveness with lowdecompression resources and high data access flexibility.

Row

ID

Date/

Time Material

Customer

Name Quantity

1 14:05 Radio Dubois 1

2 14:11 Laptop Di Dio 2

3 14:32 Stove Miller 1

4 14:38 MP3 Player Newman 2

5 14:48 Radio Dubois 3

6 14:55 Refrigerator Miller 1

7 15:01 Stove Chevrier 1

# Customers

1 Chevrier

2 Di Dio

3 Dubois

4 Miller

5 Newman

# Material

1 MP3 Player

2 Radio

3 Refrigerator

4 Stove

5 Laptop

Row

ID

Date/

Time Material

Customer

Name Quantity

1 845 2 3 1

2 851 5 2 2

3 872 4 4 1

4 878 1 5 2

5 888 2 3 3

6 895 3 4 1

7 901 4 1 1

8/9/2019 Sg 248086

17/266


1.2.2 Columnar storage

Relational databases organize data in tables that contain the data records. The differencebetween row-based and columnar (or column-based) storage is how the table is stored.

Row-based storage stores a table in a sequence of rows. Column-based storage stores a

table in a sequence of columns.

The row-based and column-based models are shown in Figure 1-4.

Figure 1-4 Row-based and column-based storage models

Both storage models have benefits and drawbacks, which are listed in Table 1-1.

Table 1-1 Benefits and drawbacks of row-based and column-based storage

Row

ID

Date/

Time Material

Customer

Name Quantity

1 845 2 3 1

2 851 5 2 2

3 872 4 4 1

4 878 1 5 2

5 888 2 3 3

6 895 3 4 1

7 901 4 1 1

Row

ID

Date/

Time Material

Customer

Name Quantity

1 845 2 3 1

2 851 5 2 2

3 872 4 4 1

4 878 1 5 2

5 888 2 3 3

6 895 3 4 1

7 901 4 1 1

Row-based Column-based

Row-based store

Column-based store

1 845 2 3 1 2 851 5 2 2 3 872 4 4 1 4 878 1 5 2

1 2 3 4 845 851 872 878 2 5 4 1 3 2 4 5

Row-based storage Column-based storage

Benefits Record data is stored together.

Easy to insert/update.

Only affected columns must be

read during the selection process

of a query.

Efficient projections.a

Any column can serve as an index.

a. Projection refers to the view on the table with a subset of columns.

Drawbacks All data must be read during selection,

even if only a few columns are involved

in the selection process.

After selection, selected rows must

be reconstructed from columns.

No easy insert/update.

8/9/2019 Sg 248086

18/266


The drawbacks of column-based storage are not as grave as they seem. In most cases, not

all attributes (that is, column values) of a row are needed for processing, especially in analyticqueries. Also, inserts or updates to the data are less frequent in an analytical environment.1 SAP HANA implements a row-based storage and a column-based storage; however, its

performance originates in the usage of column-based storage in memory. The followingsections describe how column-based storage is beneficial to query performance and how

SAP HANA handles the drawbacks of column-based storage.

Efficient query executionTo show the benefits of dictionary compression that is combined with columnar storage,Figure 1-5 shows an example of how a query is run. (Figure 1-5 refers to the table that is

shown in Figure 1-3 on page 4.)

Figure 1-5 Example of a query that is run on a table in columnar storage

The query asks to get all records with Miller as the customer name and Refrigerator as thematerial.

First, the strings in the query condition are looked up in the dictionary. Miller is represented by

the number 4 in the customer name column. Refrigerator is represented by the number 3 inthe material column. This lookup must be done only once. Subsequent comparisons with the

values in the table are based on integer comparisons, which are less resource-intensive thanstring comparisons.

In a second step, the columns are read that are par t of the query condition (that is, the

Customer and Material columns). The other columns of the table are not needed for theselection process. The columns are then scanned for values that match the query condition.

That is, in the Customer column, all occurrences of 4 are marked as selected, and in theMaterial column, all occurrences of 3 are marked.

1 An exception is bulk loads (for example, when replicating data in the in-memory database, which can be handled

differently).

Resultset 1 2 3 4 5 6 7

Customer 3 2 4 5 3 4 1

Get all records with Customer Name Miller and Material Refrigerator

# Customers

1 Chevrier

2 Di Dio

3 Dubois

4 Miller

5 Newman

# Material

1 MP3 Player

2 Radio

3 Refrigerator

4 Stove

5 Laptop

Material 2 5 4 1 2 3 4

Combine

0 0 1 0 0 1 0 0 0 0 0 0 1 0

bit-wise AND

0 0 0 0 0 1 0

Integer comparison operations

Only those columns are readwhich are part of the query condition

Dictionary lookup of the stringsStrings are only compared once!

The resulting records can be assembled from the column stores fast, because positions are known(here: 6th position in every column)

8/9/2019 Sg 248086

19/266


These selection marks can be represented as bitmaps, which are data structures that allow

efficient Boolean operations on them that are used to combine the bitmaps of the individualcolumns to a bitmap that represents the selection or records that match the entire querycondition. In this example, the record number 6 is the only matching record. Depending on the

columns that are selected for the result, the extra columns must be read to compile the entirerecord to return it. However, because the position within the column is known (record number

6), only the parts of the columns that contain the data for this record must be read.

This example shows how compression can limit not only the amount of data that must be readfor the selection process, but can simplify the selection while the columnar storage model

further reduces the amount of data that is needed for the selection process. Although theexample is simplified, it shows the benefits of dictionary compression and columnar storage.

Delta-merge and bulk insertsTo overcome the drawback of inserts or updates that affect the performance of the

column-based storage, SAP plans to implement a lifecycle management for databaserecords.2

The lifecycle management for database records in the column-store is shown in Figure 1-6.

Figure 1-6 Lifetime management of a data record in the SAP HANA column-store

The following types of storage for a table are available:

L1 Delta Storage is optimized for fast write operations. The update is performed byinserting a new entry into the delta storage. The data is stored in records, as with a

traditional row-based approach. This action ensures high performance for write, update,

and delete operations on records that are stored in the L1 Delta Storage. L2 Delta Storage is an intermediate step. Although organized in columns, the dictionary is

not as optimized as in the main storage because it appends new dictionary entries to theend of the dictionary. This action results in easier inserts, but has drawbacks regardingsearch operations on the dictionary because it is not sorted.

Main Storage contains the compressed data for fast read with a search optimizeddictionary.

2 Efficient Transaction Processing in SAP HANA Database - The End of a Column Store Myth , which is available at

this website:

http://dl.acm.org/citation.cfm?id=2213946 .

L1 Delta L2 Delta Main storeMerge

Unified Table

Update / Insert / Delete Bulk Insert

Read

Merge

http://dl.acm.org/citation.cfm?id=2213946http://dl.acm.org/citation.cfm?id=2213946

8/9/2019 Sg 248086

20/266


All write operations on a table work on the L1 Delta storage. Bulk inserts bypass L1 Delta

storage and write directly into L2 Delta storage. Read operations on a table always read fromall storages for that table. The result set is merged to provide a unified view of all data recordsin the table.

During the lifecycle of a record, it is moved from L1 Delta storage to L2 Delta storage andfinally to the Main Storage. The process of moving changes to a table from one storage to thenext one is known as Delta Merge, which is an asynchronous process. During the mergeoperations, the columnar table is still available for read and write operations.

Moving records from L1 Delta storage to L2 Delta storage involves reorganizing the record ina columnar fashion and compressing it, as shown in Figure 1-3 on page 4. If a value is not yet

in the dictionary, a new entry is appended to the dictionary. Appending to the dictionary isfaster than inserting, but results in an unsorted dictionary, which affects the data retrievalperformance.

Eventually, the data in the L2 Delta storage must be moved to the Main Storage. Toaccomplish that task, the L2 Delta storage must be locked and a new L2 Delta storage must

be opened to accept further additions. Then, a new Main Storage is created from the old MainStorage and the locked L2 Delta storage. This task is a resource-intensive and must be

scheduled carefully.

1.2.3 Pushing application logic to the database

Although the concepts that are described in 1.2.2, “Columnar storage” on page 5 speedupprocessing within the database, there is still one factor that can slow down the processing of

data. An application that is running the application logic on the data must get the data fromthe database, process it, and possibly send it back to the database to store the results.

Sending data back and forth between the database and the application usually involvescommunication over a network, which introduces an effect on communication and latency and

is limited by the speed and throughput of the network between the database and theapplication.

To eliminate this factor and increase overall performance, it is beneficial to process the data

where it is (in the database.) If the database can perform calculations and apply applicationlogic, less data must be sent back to the application and might even eliminate the need for the

exchange of intermediate results between the database and the application. This actionminimizes the amount of data transfer, and the communication between database andapplication adds less time to the overall processing time.

1.3 Dividing and conquering

The phrase “divide and conquer” (derived from the Latin saying divide et impera) typically is

used when a large problem is divided into a number of smaller, easier-to-solve problems.Regarding performance, processing huge amounts of data is a problem that can be solved by

splitting the data into smaller chunks of data, which can be processed in parallel.

8/9/2019 Sg 248086

21/266


1.3.1 Parallelization on multi-core systems

When chip manufacturers reached the physical limits of semiconductor-basedmicroelectronics with their single-core processor designs, they started to increase processorperformance by increasing the number of cores, or processing units, within a single

processor. This performance gain can be used through parallel processing only because the

performance of a single core remains unchanged.

The rows of a table in a relational database are independent of each other, which allowsparallel processing. For example, when a database table is scanned for attribute values thatmatch a query condition, the table or the set of attributes (columns) that are relevant to the

query condition can be divided into subsets and spread across the cores that are available toparallelize the query processing. Compared with processing the query on a single core, this

action reduces the time that is needed for processing by a factor equivalent to the number ofcores that are working on the query (for example, on a 10-core processor, the time that is

needed is one-tenth of the time that a single core needs).

The same principle applies for multi-processor systems. A system with eight 10-coreprocessors can be regarded as an 80-core system that can divide the processing into 80

subsets that are processed in parallel.

1.3.2 Data partitioning and scale-out

Although servers that are available today can hold terabytes of data in memory and provide

up to eight processors per server with up to 10 cores per processor, the amount of data that isstored in an in-memory database or the computing power that is needed to process such

quantities of data might exceed the capacity of a single server. To accommodate the memoryand computing power requirements that go beyond the limits of a single server, data can bedivided into subsets and placed across a cluster of servers, which forms a distributed

database (scale-out approach).

The individual database tables can be placed on different servers within the cluster. Tablesbigger than what a single server can hold can be split into several partitions horizontally (a

group of rows per partition) or vertically (a group of columns per partition), with each partitionon a separate server within the cluster.

8/9/2019 Sg 248086

22/266


8/9/2019 Sg 248086

23/266


Chapter 2. SAP HANA overview

This chapter describes the SAP HANA offering, including its architecture, components, use

cases, delivery model, and sizing and licensing aspects.


SAP HANA overview SAP HANA delivery model Sizing SAP HANA SAP HANA software licensing

2

8/9/2019 Sg 248086

24/266


2.1 SAP HANA overview

This section gives an overview of SAP HANA. The following terms are used regarding SAPHANA:

SAP HANA database

The SAP HANA database (which is also referred to as the SAP in-memory database) is ahybrid in-memory database that combines row-based, column-based, and object-based

database technology that is optimized to use the parallel processing capabilities of currenthardware. It is the heart of SAP offerings, such as SAP HANA.

SAP HANA appliance (SAP HANA)

SAP HANA is a flexible, data source-neutral appliance with which you can analyze largevolumes of data in real time without needing to materialize aggregations. It is a

combination of hardware and software and is delivered as an optimized appliance withSAP’s hardware partners for SAP HANA.

For the sake of simplicity, this book uses the terms SAP HANA, SAP in-memory database,SAP HANA database, and SAP HANA appliance synonymously. It covers only the SAP

in-memory database as part of the SAP HANA appliance. Where required, we ensure that thecontext makes it clear which part is being described.

2.1.1 SAP HANA architecture

Figure 2-1 shows the high-level architecture of the SAP HANA appliance. The most important

software components of the SAP HANA database are described in 3.1, “SAP HANA softwarecomponents” on page 20.

Figure 2-1 SAP HANA architecture

SAP HANA Appliance

SAP HANA DatabaseSession Management

Persistency Layer Page

ManagementLogger

Relational Engines

Row

Store

Column

Store

Persistent StorageData Volumes Log Volumes

Request processing / Execution Control

SQL Script

SQL MDX

Calculation Engine

Transaction

Manager

Authorization

Manager

Metadata

Manager

SAP CAR

JVM

LM Structure

SAP HANA

Studio

SAP HANA

Client

SAP HANA

Client

SAP Host Agent

Software Update

Manager

SAP HANA

Studio Repository

8/9/2019 Sg 248086

25/266

Chapter 2. SAP HANA overview13

SAP HANA databaseThe heart of the SAP HANA database is the relational database engines. The SAP HANAdatabase features the following engines:

The column-based store

Stores relational data in columns, which are optimized holding tables with large amounts

of data that can be aggregated in real time and used in analytical operations. The row-based store

Stores relational data in rows, as traditional database systems do. This row store is more

optimized for row operations, such as frequent inserts and updates. It has a lowercompression rate and query performance is much lower compared to the column-based

store.

The engine that is used to store data can be selected on a per-table basis when the table iscreated. A table can be converted from one type to another type. Tables in the row-store are

loaded at start time, but tables in the column-store can be loaded at start or on demandduring normal operation of the SAP HANA database.

Both engines share a common persistency layer, which provides data persistency that isconsistent across both engines. There is page management and logging, as with traditionaldatabases. Changes to in-memory database pages are persisted through savepoints that are

written to the data volumes on persistent storage, which often is hard disk drives (HDDs).Every transaction that is committed in the SAP HANA database is persisted by the logger of

the persistency layer in a log entry that is written to the log volumes on persistent storage.The log volumes use flash technology storage for high I/O performance and low latency.

The relational engines can be accessed through various interfaces. The SAP HANA databasesupports SQL (JDBC/ODBC), MDX (ODBO), and BICS (SQL DBC). The calculation engine

allows calculations to be performed in the database without moving the data into theapplication layer. It also includes a business functions library that can be called by

applications to perform business calculations close to the data. The SAP HANA-specific SQLScript language is an extension to SQL that can be used to push down data-intensive

application logic into the SAP HANA database.

2.1.2 SAP HANA appliance

The SAP HANA appliance consists of the SAP HANA database and adds components thatare needed to work with, administer, and operate the database. It contains the repository filesfor the SAP HANA studio, which is an Eclipse-based administration and data-modeling tool

for SAP HANA. It also includes the SAP HANA client, which is a set of libraries that isrequired for applications to connect to the SAP HANA database. The SAP HANA studio and

the client libraries often are installed on a client PC or server.

The Software Update Manager (SUM) for SAP HANA is the framework that allows for the

automatic download and installation of SAP HANA updates from the SAP Marketplace andother sources by using a host agent. It also allows distribution of the studio repository to theusers.

The Lifecycle Management (LM) Structure for SAP HANA is a description of the current

installation and is, for example, used by SUM to perform automatic updates.

For more information about software components, see 3.1, “SAP HANA softwarecomponents” on page 20.

8/9/2019 Sg 248086

26/266


2.2 SAP HANA delivery model

SAP deployed SAP HANA as an integrated solution that combines software and hardware,which is frequently referred to as the SAP HANA appliance. As with SAP NetWeaverBusiness Warehouse Accelerator (SAP NetWeaver BW Accelerator), SAP partners withseveral hardware vendors to provide the infrastructure that is needed to run the SAP HANA

software. Lenovo partnered with SAP to provide an integrated solution.

Over the last few years, SAP gained more experience with running SAP HANA in productionenvironments, so a second delivery model is also supported, which is known as tailored datacenter integration (TDI). TDI aims to integrate clients’ hardware from different vendors onwhich to deploy SAP HANA. Both approaches are described briefly in this chapter. The rest ofthis book covers only the appliance delivery model.

2.2.1 SAP HANA as an appliance

Ensuring the highest customer satisfaction, SAP HANA is available as an appliance fromdifferent hardware partners. The partners select the components of the appliance and tune it

specifically for use with SAP HANA. Infrastructure for SAP HANA must run through an SAPcertification process to ensure that certain performance requirements are met. Only certified

configurations are supported by SAP and the respective hardware partner. Theseconfigurations must adhere to the following requirements and restrictions to provide a common

platform across all hardware providers:

Only certain Intel Xeon processors can be used.

All configurations must provide a certain main memory per core ratio, which is defined by

SAP to balance CPU processing power and the amount of data that is processed.

All configurations must meet minimum redundancy and performance requirements forvarious load profiles. SAP tests for these requirements as part of the certification process.

The capacity of the storage devices that are used in the configurations must meet certain

criteria that are defined by SAP. The networking capabilities of the configurations must include 10 Gb Ethernet for the SAP

HANA software.

By imposing these requirements, SAP can rely on the availability of certain features and

ensure a well-performing hardware platform for their SAP HANA software. Theserequirements give the hardware partners enough room to develop an infrastructurearchitecture for SAP HANA, which adds differentiating features to the solution. For more

information about the benefits of the Lenovo solution, see Chapter 5, “Lenovo System xsolutions for SAP HANA” on page 57.

2.2.2 SAP HANA tailored data center integration

To allow for an existing infrastructure to be integrated and reused when SAP HANA isdeployed, clients can follow the TDI delivery model. Storage and networks that fulfill certain

criteria can be used to run SAP HANA. Among others, these criteria include storage andnetwork performance.

Implementing SAP HANA by following the TDI model requires close collaboration between

the client, SAP, and the vendor of the infrastructure element that is integrated. For moreinformation about this SAP delivery model, see this website:

http://www.saphana.com/docs/DOC-3633

http://www.saphana.com/docs/DOC-3633http://www.saphana.com/docs/DOC-3633

8/9/2019 Sg 248086

27/266

Chapter 2. SAP HANA overview15

IBM released a white paper that gives architectural guidance about how to implement an SAP

HANA environment with IBM storage products while following the TDI model. The white paperis available for download at this website:

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102347

EMC and IBM released a joint paper about the use of the TDI method to configure a scale-out

environment with EMC Symmetrix VMAX Storage and IBM GPFS. It is available for downloadat this website:

https://community.emc.com/docs/DOC-35182

Only certain components are eligible for integration. For more information about the list ofcertified enterprise storage for SAP HANA, see this website:

http://scn.sap.com/docs/DOC-48516

2.3 Sizing SAP HANA

In this section, we introduce the concept of T-shirt sizes and the new shortname concept forSAP HANA. Then, we give a brief introduction about how to size an SAP HANA system.

2.3.1 Memory per core ratio for SAP HANA appliances

For in-memory computing appliances, such as SAP HANA, the amount of main memory is

important. In-memory computing brings data that is kept on disk into main memory. Thisaction allows for much faster processing of the data because the CPU cores do not have towait until the data is loaded from disk to memory, which means each CPU is better used.

There is a certain ideal memory per core ratio. If an in-memory appliance has too muchmemory per CPU core, the cores cannot fully use the advantage of fast data access. If an

in-memory appliance has too little memory per CPU core, the cores are underused and

remain idle. In this case, your system does not run as fast as it theoretically can.

This memory per core ratio is defined by SAP. Lenovo is building solutions for SAP HANA

following this memory per core ratio.

T-shirt sizes for SAP HANAWhen SAP introduced SAP HANA into the market, they defined so-called T-shirt sizes tosimplify the sizing and to limit the number of hardware configurations to support, which

reduces complexity. Each T-shirt size reflects a multiple of the memory to core ratio that wasinitially allowed by SAP.

The SAP hardware partners provide configurations for SAP HANA according to one or more

of these T-shirt sizes. The T-shirt sizes for SAP HANA are listed in Table 2-1.

Table 2-1 SAP HANA T-shirt sizes

SAP T-shirt size XS S and S+ M and M+ L

Compressed data in memory 64 GB 128 GB 256 GB 512 GB

Server main memory 128 GB 256 GB 512 GB 1024 GB

Number of CPUs 2 2 4 8

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102347https://community.emc.com/docs/DOC-35182http://scn.sap.com/docs/DOC-48516https://community.emc.com/docs/DOC-35182http://scn.sap.com/docs/DOC-48516http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102347

8/9/2019 Sg 248086

28/266


The T-shirt sizes S+ and M+ denote the following upgradeable versions of the S and M sizes:

S+ delivers capacity that is equivalent to S, but the hardware is upgradeable to an M size. M+ delivers capacity that is equivalent to M, but the hardware is upgradeable to an L size.

These T-shirt sizes are used when relevant growth of the data size is expected.

In addition to these standard T-shirt sizes (which apply to all use cases of SAP HANA) thereare configurations that are specific to and limited for use with SAP Business Suiteapplications that are powered by SAP HANA. These other T-shirt sizes are listed in Table 2-2.

Table 2-2 T-shirt sizes for SAP Business Suite that are powered by SAP HANA

The workload for the SAP Business Suite applications has different characteristics. It is lessCPU-bound and more memory-intensive than a standard SAP HANA workload. Therefore,the memory per core ratio is different than for the standard T-shirt sizes. All workloads can be

used on the T-shirt sizes that are listed in Table 2-1 on page 15, including SAP Business Suiteapplications with SAP HANA as the primary database. The T-shirt sizes that are listed in

Table 2-2 are specific to and limited for use with SAP Business Suite applications that arepowered by SAP HANA only.

For more information about which of the SAP Business Suite applications are supported bySAP HANA as the primary database, see 4.5.3, “SAP Business Suite that is powered by SAP

HANA” on page 53.

For more information about T-shirt size mappings to Lenovo eX5 based building blocks, see

6.1, “eX5 based environments” on page 126.

New concept of shortnames for SAP HANAWith the introduction of the latest processor generation by Intel in February 2014, themaximum number of cores per CPU socket increased from 10 to 15. Each core also provides

more compute power than a previous generation core. This increase lead to various memoryper core ratios that results in many different solution offerings for the same T-shirt size.

To simplify the issue and avoid confusion, Lenovo introduced the following generic naming

schema that replaces T-shirt sizes. Instead of S, M, L, and so on, names for different types ofbuilding blocks with the XXX-YS-NNNN-Z (dashes can also be left out) naming conventionare used, where:

XXX is the server’s model type YS is the number of installed processors (or sockets) NNNN is the memory amount in gigabytes Z indicates a stand-alone (S) or cluster (C) node

For example, model AC3-2S-256-S represents a stand-alone, 4S server (AC3-models have

four sockets) with two processors that are installed and 256 GB of memory. This modelreplaces former T-shirt size S.

A model AC4-8S-1024-C represents an 8-socket cluster node (AC4-models have eight

sockets) with eight processors that are installed and 1 TB of main memory.

SAP T-shirt size L XL XXL

Compressed data in memory 512 GB 1 TB 2 TB

Server main memory 1 TB 2 TB 4 TB

Number of CPUs 4 8 8

8/9/2019 Sg 248086

29/266

8/9/2019 Sg 248086

30/266


2.4 SAP HANA software licensing

As described in 2.2, “SAP HANA delivery model” on page 14, the prevalent deploymentmethod of SAP HANA is an appliance-like delivery model. Although the hardware partners

deliver the infrastructure, including the operating system and middleware, the license for theSAP HANA software must be obtained directly from SAP.

The SAP HANA software is available in two editions (platform and enterprise edition) and the

SAP HANA software licensing depends on the use case. For more information about usecases for SAP HANA, see Chapter 4, “SAP HANA integration scenarios” on page 35.

Tip: Licensing SAP HANA is handled by SAP and there are different options available,depending on the use case. Because metrics can always change, discuss licensing

options for your particular use case with SAP.

8/9/2019 Sg 248086

31/266


Chapter 3. Software components and data

replication methods

This chapter describes the purpose of individual software components of the SAP HANAsolution and introduces available replication technologies.


SAP HANA software components Data replication methods for SAP HANA

3

8/9/2019 Sg 248086

32/266


3.1 SAP HANA software components

The SAP HANA solution is composed of the main software components that are described inthe following sections:

3.1.1, “SAP HANA database” on page 20

3.1.2, “SAP HANA client” on page 21 3.1.3, “SAP HANA studio” on page 22 3.1.4, “SAP HANA studio repository” on page 26 3.1.5, “SAP HANA landscape management structure” on page 26 3.1.6, “SAP host agent” on page 27 3.1.7, “SAP HANA Lifecycle Manager” on page 27 3.1.8, “SAP HANA Lifecycle Management tools” on page 28

The locations of these components are shown in Figure 3-1.

Figure 3-1 Distribution of software components that are related to SAP HANA

3.1.1 SAP HANA database

The SAP HANA database is the heart of the SAP HANA offering and the most importantsoftware component that runs on the SAP HANA appliance.

SAP HANA is an in-memory database that combines row-based and column-based database

technology. All standard features that are available in other relational databases aresupported (for example, tables, views, indexes, triggers, and SQL interface).

In addition to these standard functions, the SAP HANA database offers modeling capabilitiesthat with which you can define in-memory transformation of relational tables into analytic

views. These views are not materialized; therefore, all queries are providing real-time resultsthat are based on the content of the underlying tables.

SAP HANA Appliance

SAP HANA

client

SAP HANA

studio

repository

SAP host

agent

SAP HANA

LM structure

SAP HANA

Lifecycle

Manager

SAP HANA

studio

Other optional components:

SMD Agent

(optional)

Application

Server

SAP HANA

client

User

workstation

SAP HANA

studio

(optional)

SAP HANA

client

(optional)

Application

Function

Library

SAP

liveCache

ApplicationsSAP HANA

database

Data Modeling

Row Store

Column Store

8/9/2019 Sg 248086

33/266

Chapter 3. Software components and data replication methods21

Another feature that extends the capabilities of the SAP HANA database is the SQLscript

programming language, with which you can capture transformations that might not be easy todefine by using simple modeling.

The SAP HANA database also can be integrated with external applications, such as an SAP

application environment (for example, ERP). By using these possibilities, customers canextend their models by implementing existing statistical and analytical functions that were, forexample, developed in ABAP.

For more information about the internal structures of the SAP HANA database, see

Chapter 2, “SAP HANA overview” on page 11.

3.1.2 SAP HANA client

The SAP HANA client is a set of libraries that are used by external applications to connect tothe SAP HANA database.

The following interfaces are available after the SAP HANA client libraries are installed:

SQLDBC

An SAP native database SDK that can be used to develop new custom applications thatare working with the SAP HANA database.

OLE DB for OLAP (ODBO) (available for Windows only)

ODBO is a Microsoft driven industry standard for multi-dimensional data processing. Thequery language that is used with ODBO is the Multidimensional Expressions (MDX)

language.

Open Database Connectivity (ODBC)

The ODBC interface is a standard for accessing database systems, which was originallydeveloped by Microsoft.

Java Database Connectivity (JDBC)

JDBC is a Java based interface for accessing database systems.

The SAP HANA client libraries are delivered in 32-bit and 64-bit editions. It is important

always to use the correct edition that is based on the architecture of the application that usesthis client. The 32-bit applications cannot use 64-bit client libraries and vice versa.

To access the SAP HANA database from Microsoft Excel, you also can use a special 32-bit

edition of the SAP HANA client that is called SAP HANA client package for Microsoft Excel.

The SAP HANA client is compatible with earlier versions; that is, the revision of the clientmust be the same or higher than the revision of the SAP HANA database.

The SAP HANA client libraries must be installed on every machine where connectivity to the

SAP HANA database is required, including all servers and user workstations that are hostingapplications that are directly connecting to the SAP HANA database (for example, SAP

BusinessObjects Client Tools or Microsoft Excel).

Whenever the SAP HANA database is updated to a more recent revision, all clients that areassociated with this database also must be upgraded. For more information about how to

install the SAP HANA client, see the official SAP guide SAP HANA Database - ClientInstallation Guide , which is available at this website:

http://help.sap.com/hana_platform

http://help.sap.com/hana_platformhttp://help.sap.com/hana_platform

8/9/2019 Sg 248086

34/266


3.1.3 SAP HANA studio

The SAP HANA studio is a graphical user interface (GUI) that is required to work with local orremote SAP HANA database installations. It is a multipurpose tool that covers all of the mainaspects of working with the SAP HANA database. The user interface is slightly different for

each function.

The SAP HANA studio does not depend on the SAP HANA client.

The following main function areas are provided by the SAP HANA studio:

Database administration

The key functions are stopping and starting the SAP HANA databases, status overview,monitoring, performance analysis, parameter configuration, tracing, and log analysis.

The SAP HANA studio user interface for database administration is shown in Figure 3-2.

Figure 3-2 Administration console (overview)

8/9/2019 Sg 248086

35/266


Security management

This function area provides tools that are required to create users, define and assign roles,

and grant database privileges. An example of the user definition window is shown inFigure 3-3.

Figure 3-3 User definition window

Data management

These functions can be used to create, change, or delete database objects (such astables, indexes, and views), and include commands to manipulate data (for example,

insert, update, delete, or perform a bulk load). An example of the table definition window is

shown in Figure 3-4.

Figure 3-4 Table definition window

8/9/2019 Sg 248086

36/266


Modeling

This GUI is used to work with models (metadata descriptions about how source data is

transformed in resulting views), including defining new custom models and adjusting ordeleting models. A simple analytic model is shown in Figure 3-5.

Figure 3-5 Modeling interface (analytic view)

Content management

By using these functions, you can organize models in packages, define delivery units for

transport into an SAP HANA system, or export and import individual models or wholepackages. Content management functions are accessible from the main window in the

modeler perspective, as shown in Figure 3-6.

Figure 3-6 Content functions in the main window of modeler perspective

8/9/2019 Sg 248086

37/266


Replication management

Data replication into the SAP HANA database is controlled from the data provisioning

window in the SAP HANA studio, in which new tables can be scheduled for replication,suspended, or replication for a particular table can be interrupted.

An example of a data provisioning window is shown in Figure 3-7.

Figure 3-7 Data provisioning window

Lifecycle Management

The SAP HANA solution can be used to download and automatically install updates toSAP HANA software components. This function is controlled from the Lifecycle Manager

window in the SAP HANA studio, as shown in Figure 3-8.

Figure 3-8 Lifecycle Manager window

8/9/2019 Sg 248086

38/266


The SAP HANA database queries are used indirectly by using front-end components, such as

SAP BusinessObjects BI 4.0 clients. Therefore, the SAP HANA studio is required only foradministration or development and is not needed for users.

The SAP HANA studio runs on the Eclipse platform; therefore, every user must have a recent

version of the Java Runtime Environment (JRE) installed that uses the same architecture(64-bit SAP HANA studio has 64-bit JRE as a prerequisite).

Currently, Windows 32-bit, Windows 64-bit, and Linux 64-bit are the supported platforms.

The SAP HANA studio also is compatible with earlier versions; therefore, the revision level of

the SAP HANA studio must be the same or higher than the revision level of the SAP HANAdatabase. However, based on practical experience, the preferred approach is to keep SAPHANA studio on same revision level as the SAP HANA database whenever possible.

Installation and parallel usage of multiple revisions of SAP HANA studio on one workstation ispossible. When one SAP HANA studio instance for multiple SAP HANA databases is used,

the revision level of the SAP HANA studio must be the same or higher revision level than thehighest revision level of the SAP HANA databases to which you are connecting.

SAP HANA studio must be updated to a more recent version on all workstations whenever

the SAP HANA database is updated. This process can be automated by using UpdateServer, which can be configured by using SAP HANA Lifecycle Manager (HLM). (For more

information about HLM, see 3.1.7, “SAP HANA Lifecycle Manager” on page 27.) The use ofHLM is the best way to keep installations of SAP HANA studio synchronized with the SAP

HANA database revision.

For more information about how to install the SAP HANA studio, see the official SAP guide,

SAP HANA Database - Studio Installation Guide , which is available at this website:


3.1.4 SAP HANA studio repository

Because SAP HANA studio is an Eclipse-based product, it can benefit from all the standardfeatures that are offered by this platform. One of these features is the ability to automatically

update the product from a central repository on the SAP HANA server.

The SAP HANA studio repository is initially installed during the deployment of the SAP HANA

appliance and must be updated manually when the SAP HANA database is updated. Thisrepository can then be used by all SAP HANA studio installations to download andautomatically install new versions of code.

For more information about how to install the SAP HANA studio repository, see the officialSAP guide, SAP HANA Database - Studio Installation Guide , which is available at this

website:


3.1.5 SAP HANA landscape management structure

The SAP HANA landscape management (LM) structure (lm_structure) is an XML file thatdescribes the software components that are installed on a server. The information in this filecontains the following items:

System ID (SID) of the SAP HANA system and host name A stack description, including the edition (depending on the license schema) Information about the SAP HANA database, including the installation directory

http://help.sap.com/hana_platformhttp://help.sap.com/hana_platformhttp://help.sap.com/hana_platformhttp://help.sap.com/hana_platform

8/9/2019 Sg 248086

39/266


Information about the SAP HANA studio repository, including its location Information about the SAP HANA client, including its location Information about the host controller

The LM structure description also contains revisions of individual components; therefore, it

must be upgraded when the SAP HANA database is upgraded. Information that is containedin this file is used by the System Landscape Directory (SLD) data suppliers and by the SAPHANA HLM.

3.1.6 SAP host agent

The SAP host agent is a standard part of every SAP installation. In an SAP HANAenvironment, it is important in the following situations:

Automatic update by using SAP HANA LM Remote starting and stopping of SAP HANA database instances

3.1.7 SAP HANA Lifecycle Manager

In older SAP HANA releases (SAP HANA SP05 and before), the following tools wereavailable for update, configuration, and customization tasks:

Software Update Manager (SUM) for SAP HANA that is focused on automating updates ofvarious SAP HANA components and the SAP HANA database.

SAP HANA On-site Configuration Tool (OCT) for SAP HANA automated customization of

SAP HANA appliances, which performs postinstallation steps, such as deployment ofother components (such as adding or removing a host or deploying a secondary system).

In the latest SAP HANA release (SPS07), these tools are marked as deprecated and

replaced by SAP HLM. The SAP HLM is a tool that automates many installation,configuration, and deployment tasks that are related to SAP HANA environments. It offers the

following functions:

Rename an SAP HANA system (SID, instance number, or host name) Configure SAP Landscape Transformation (SLT) replication Configure the SAP HANA connection to System Landscape Directory (SLD) Add/Remove Solution Manager Diagnostics (SMD) agent Add/Remove extra SAP HANA system (MCOS installation) Add/Remove hosts to/from scale-out (or distributed) SAP HANA installation Configure SAP HANA system internal network Update SAP HANA System - Apply Support Package Stack Update SAP HANA System - Apply Single Support Packages Add/Update Application Function Libraries (AFL) on an SAP HANA system Add/Update SAP liveCache Applications (LCA) on an SAP HANA system Add SAP HANA Smart Data Access (SDA) on an SAP HANA system

SAP HANA Lifecycle Manager can be run in the following ways:

Locally or remotely as part of SAP HANA studio Locally from the Linux command line on an SAP HANA server node Locally or remotely through a web interface

For more information about SAP HANA Lifecycle Manager, see the official SAP guide, SAPHANA Update and Configuration Guide , which is available at this website:


http://help.sap.com/hana_platformhttp://help.sap.com/hana_platform

8/9/2019 Sg 248086

40/266


3.1.8 SAP HANA Lifecycle Management tools

The SAP HANA Unified Installer was a tool that was targeted to be used by SAP HANAhardware partners. It automatically installed all required software components on the SAPHANA appliance according to SAP requirements and specifications.

With the release of SAP HANA SPS07, the SAP HANA Unified Installer is marked asdeprecated. However, it is still available as a part of the standard delivery package.

SAP HANA LM tools (also referred to and available in Linux as hdblcm or hdblcmgui) aredelivered as the replacement for SAP HANA Unified Installer. Although hdblcm is a text-basedLinux command-line utility that can be run in interactive or batch mode, its counterparthdblcmgui delivers the same functions in a GUI.

Like Unified Installer, these two utilities are intended for hardware vendors to automate the

initial deployment of SAP HANA on their appliance models. System administrators areexpected to use SAP HLM, as described in 3.1.7, “SAP HANA Lifecycle Manager” on

page 27.

The SAP HANA LM tools include the following features:

Install SAP HANA system (single-node or scale-out)

Add host to scale-out SAP HANA system

Enable or disable auto-start of SAP HANA database instance

Regeneration of SSL certificates that are used by SAP HANA LM

Installation and update of the following SAP HANA components:

– Application Function Library– SAP HANA Client

– SAP HANA Studio– SAP HANA Database server– SAP HANA Lifecycle Manager (HLM)

– SAP liveCache applications

Update of server-side studio repository

Install and update SAP host agent

For more information about SAP HANA LM tools, see the official SAP guide, SAP HANAServer Installation Guide , which is available at this website:


3.1.9 Solution Manager Diagnostics agent

SAP HANA can be connected to SAP Solution Manager 7.1, SP03 or higher.1 It is preferable

to use SP05 or higher.

The SMD provides a set of tools to monitor and analyze SAP systems, including SAP HANA.It also provides a centralized method to trace problems in all systems that are connected to

an SAP Solution Manager system.

1 With monitor content update and more SAP notes for SP02

http://help.sap.com/hana_platformhttp://help.sap.com/hana_platformhttp://help.sap.com/hana_platform

8/9/2019 Sg 248086

41/266


The SMD agent is an optional component, which can be installed on the SAP HANA

appliance. It enables diagnostic tests of the SAP HANA appliance through SAP SolutionManager. The SMD agent provides access to the database logs and the file system, andcollects information about the system’s CPU and memory consumption through the SAP host

agent.

For more information about how to deploy SMD agent, see the official SAP guide, SAP HANAUpdate and Configuration Guide , which is available at this website:


3.2 Data replication methods for SAP HANA

Data can be written to the SAP HANA database directly by a source application or replicatedby using replication technologies.

The following replication methods are available for use with the SAP HANA database:

Trigger-based replication

This method is based on database triggers that are created in the source system to recordall changes to monitored tables. These changes are then replicated to the SAP HANAdatabase by using the SAP Landscape Transformation system.

ETL-based replication

This method uses an Extract, Transform, and Load (ETL) process to extract data from the

data source, transform it to meet the business or technical needs, and load it into the SAPHANA database. The SAP BusinessObject Data Services application is used as part ofthis replication scenario.

Extractor-based replication

This approach uses the embedded SAP NetWeaver Business Warehouse (SAPNetWeaver BW) that is available on every SAP NetWeaver based system. SAP

NetWeaver BW starts an extraction process by using available extractors and thenredirects the write operation to the SAP HANA database instead of the local Persistent

Staging Area (PSA).

Log-based replicati

Documents

Sg 248086