Monthly Archive: March 2015

BASIC ARCHITECTURE OF SAP HANA DB

SAP HANA needs at least 128GB of RAM, ideally 1 core can control 16GB of memory, SAP HANA can use 90% of available memory

Sap HANA and SAP HANA Studio should be the same version to avoid issues.

The disk layer has the data volumes and the log volumes and this is a non volatile data storage.

The storage engine helps in data pages and exchange from RAM to disks

Relational engines has the column store and row store the place where it stores data in the RAM

Process or execution engines- process and executes the queries

External interfaces – communicates with HANA Databases, helps in admin data loads and queries.

Data Services Replication

Data Services Replication

Data Integrator has been moving data into and out of SAP sources for many years. Data integrator can work with  almost any database to extarct and load data and both in batch and real time mode making it a robust tool for data replication.

Examples of databases /Apps that can connect to data integrator are sybase,oracle,my sql,COBOL,informix,DB2,MS excel,webservices,flat files,jd edwards,oracle apps,terradata,SAP BW,SAP ERP,XML File(batch),Siebel,XML messages (realtime)

Usage of SAP HANA

SAP Landscape Virtualization manager:

SAP LVM is sued to start and stop of SAP HANA with in SAP landscapes.

SAP Solution Manager:

For Monitoring of SAP HANA using DBACOCKPIT

SAP Support OSS:

For remote support to HANA database.

SAP SMP service market Place:

For downloading patches and support packs.

SAP HANA Studio:

For HANA Admin and data modeling

Data Extraction Connection (DXC):

Data from SAP Business content datasource extractor

SAP landscape transformation (SLT):

For Real Time replication

SAP Data Services:

For ETL based loading

HANA Information Composer:

For easy uploading of  data

SAP HANA UI for Information Access:

For search capability in SAP HANA

SAP Business Objects BI:

For analytics

SAP NW 7.3 BW:

For Primary Persistance  of SAP NW7.3 as ABAP

In memory APPS:

For direct access via SAP client

R runtime:

For direct integration with R runtime libraries

 

What to choose in SAP HANA-Row Store or Column Store??

What to choose in SAP HANA-Row Store or Column Store??

SQL queries involving aggregation functions take a lot of time on huge amounts of data because every single row is touched to collect the data for the query response.
In columnar tables, this information is stored physically next to each other, significantly increasing the speed of certain data queries. Data is also compressed, enabling shorter loading times.
Conclusion:

To enable fast on-the-fly aggregations, ad-hoc reporting, and to benefit from compression mechanisms it is recommended that transaction data is stored in a column-based table.

The SAP HANA data-base allows joining row-based tables with column-based tables. However, it is more efficient to join tables that are located in the same row or column store. For example, master data that is frequently joined with transaction data should also be stored in column-based tables.

Important points about column table:

  1. HANA modeling views are only possible for column tables. Row based tables cannot be used in modeling views.
    2. Replication Server creates SAP HANA tables in column store by default.
    3. Data Services also creates target tables in column store as default for SAP HANA database
    4. The data storage type of a table can be modified from Row to Column storage with the SQL command or using HANA Studio

What is Row Store and Column Store Approach of SAP HANA

What is Row Store and Column Store Approach of SAP HANA

Row based tables:

It is the traditional Relational Database approach

It store a table in a sequence of rows

Column based tables:

It store a table in a sequence of columns i.e. the entries of a column is stored in contiguous memory locations.

SAP HANA is highly optimized for column-order storage.

SAP HANA uses and support both row-based and column-based approach making it very powerful and efficient for processing huge data quickly

Row based tables benefits:

The application needs to only process a single record at one time (many selects and/or updates of single records).

The application needs to access a complete record (or row).

Neither aggregations nor fast searching are required.

The table has a small number of rows (e. g. configuration tables, system tables).

Row based tables dis-advantages:

In case of analytic applications where aggregation are used and fast search and processing is required. In row based tables all data in a row has to be read even though the requirement may be to access data from a few columns.

Row store compression is very limited.

Advantages of column-based tables?

Faster Data Access:

Only affected columns have to be read during the selection process of a query. Any of the columns can serve as an index.

High Compression:

Columnar data storage allows highly efficient compression because the majority of the columns contain only few distinct values (compared to number of rows).

parallel Processing capacbility

In a column store, data is already vertically partitioned. This means that operations on different columns can easily be processed in parallel. If multiple columns need to be searched or aggregated, each of these operations can be assigned to a different processor core