Skip to Content

Table partitioning is a data organization scheme in which table data is divided across multiple storage objects called data partitions.

In SAP HANA database, it is possible to split column-store tables horizontally into disjunctive sub-tables or partitions. The SAP HANA database supports several redistribution operations that use complex algorithms to evaluate the current distribution and determine a better distribution depending on the situation. Partitioning is typically used in distributed systems, but it may also be beneficial for single-host systems. Partitioning is transparent for SQL queries and data manipulation language statements.

In a distributed SAP HANA system, tables are assigned to an index server on a particular host at their time of creation, but this assignment can be changed. In certain situations, it is even necessary.

A non-partitioned table of SAP HANA database cannot store more than 2,000,000,000 (2 billion) rows.

For example, in SAP HANA side-by-side implementation, SLT will stop data replication when SAP HANA table reaches 2 billion records.

For simplicity, here I have discussed (with proper screen-shots) only Single-Level Partitioning with all the three partitioning specifications –
i) Hash, Range and Round-robin;
ii) I have shown the steps for re-distribution of all the partitions to different hosts in a distributed SAP HANA database;
iii) And how to change a partitioned table into a non-partitioned table also recorded here.

http://debajitb.wix.com/debajitbanerjee/apps/blog/table-partitioning-in-sap-hana-database

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

  1. Miguel Figueiredo

    Hello Debajit,

    Nice approach about table partitioning on HANA. I got a customer side-car implemantion that today are facing issues with high memory usage because tables grow over time. Thus, the question is if partitioning will help even considering that current system is single node and has no additional nodes. The intention is to allow HANA works on most accessed data by keeping related partition in-memory. Does it make sense? If does, should we use range partitioning, right?

    (0) 
    1. Debajit Banerjee Post author

      Hi Naveen,

      This document was created sometimes back..and currently I do not have facility to check it hands-on the same. So I do not have clear answer for your query.

      But as per the Create Table syntax, it is not possible. :

      CREATE [<table_type>] TABLE <table_name> <table_contents_source> [<logging_option>] [<auto_merge_option>]

              [<unload_priority_clause>] [<schema_flexibility_option>] [<partition_clause>] [<group_option>]

              [<location_clause>] [<replica_clause>] [<global_temporary_option>] [<series_clause>] [<unused_retention_period_option>]

      | CREATE VIRTUAL TABLE <table_name> <remote_location_clause>

      | CREATE TABLE <asynchronous_replica_clause>

      Also, the asynchronous table having some limitation like replication works within a single SAP HANA scale-out landscape.

      Thanks & regards,

      Debajit

      (0) 
  2. Nadar John

    Dear Debajit,

     

    Thanks for the information, this is very useful blog for us.

    Should we have to do the partition on all the primary field of table or have to selectively choose the field for partition ?

     

    Regards

    (0) 

Leave a Reply