SAP Knowledge Base Article

2044468 - FAQ: SAP HANA Partitioning

Component: HAN-DB-ENG (SAP HANA > SAP HANA Database > SAP HANA DB Engines), Version: 340, Released On: 11.02.2025

Symptom
You have a question related to SAP HANA partitioning.

Environment
SAP HANA

Cause
1. Where do I find detailed information about partitioning?
2. Which indications exist for issues related to SAP HANA partitioning?
3. How can I check and evaluate the current partitioning in a system?
4. What does partitioning in SAP HANA environments mean?
5. Is partitioning available for both row store and column store?
6. Is partitioning transparent for the application?
7. For what reasons is partitioning required or useful?
8. What kind of problems can be introduced by partitioning?
9. Which partitioning types exist?
10. Is LIST partitioning available?
11. What is single-level and multi-level partitioning?
12. Are locks involved when a table is partitioned?
13. Which best practices exist for partitioning tables?
14. How can partitioning changes be implemented?
15. How can the consistency of partitions be checked?
16. Is it possible to truncate a partition?
17. How should tables be partitioned in BW environments?
18. Is the partitioning information kept during homogeneous SAP HANA system copies?
19. Is the partitioning information kept during transports?
20. Is the partitioning information kept during ABAP table conversions and SAP upgrades?
21. My table has a partition specification, but it shows only PART_ID 0 in M_CS_TABLES. Is this correct?
22. Where can I see which partitions are loaded into memory?
23. Is it possible to load a single partition only?
24. Are cold partitions for aging and time-selection tables pre-loaded?
25. How many partitions are allowed for one table?
26. Which data types are allowed for partitioning columns?
27. Are there specific partitioning recommendations for certain SAP applications and tables?
28. Is there a way to automatize the creation of new range partitions?
29. How can I check the progress of an ongoing partitioning activity?
30. What does _SYS_SPLIT in SAP HANA monitoring views and traces mean?
31. What standard partitioning approach is used during migrations?
32. What should be considered in terms of terminating long running partitioning operations?
33. How can partitioning operations be traced?
34. Can range partitions overlap?
35. Which errors can happen in relation to partitioning?
36. What are typical partitioning runtimes?
37. Are there specific scenarios where partition pruning isn't possible?
38. What are the main partitioning phases?
39. How can the performance of partitioning activities be improved?
40. How does an example for partitioning look like?
41. How can the job progress details be interpreted for partitioning tasks?
42. What are tables with names starting with "_SYS_OMR_"?
43. What kind of resources are required during partitioning?
44. What is heterogeneous partitioning?
45. Which types of partition pruning exist?
46. How can database requests be restricted to a subset of partitions of a table?
47. What has to be considered for secondary system replication sites when doing partitioning?
48. How can some small, but not completely empty partitions be merged efficiently?
49. What are differences between standard and online partitioning?
50. Is the online option available for all partition operations?
51. How can I check to which hash partition a specific value would map?
52. Can I split a partition by only moving a smaller amount of data to a new partition?
53. Is it necessary to keep the application informed about repartitioning on SAP HANA level?
54. Is it possible to define explicit names for partitions?

Resolution

1. Where do I find detailed information about partitioning?

General information related to partitioning is contained in the SAP HANA Administration Guide.
In general, we distinguish between standard and online partitioning, see What are differences between standard and online partitioning? for more details. For historic reasons, standard partitioning is often referred to as offline partitioning although meanwhile the locking is minimized for this
partitioning type.

2. Which indications exist for issues related to SAP HANA partitioning?

The following SAP HANA alerts indicate problems in the memory area:

Aler Name Description

t

17 Record count of non-partitioned column-store tab Determines the number of records in non-partitioned column-store tables. Current table size is not critical. Partitioning need only be considered if tables are expected to grow rapidly (a non-partitioned table cannot contain more than 2,147,483,648 (2 bil
les lion) rows).

20 Table growth of non-partitioned column-store tabl Determines the growth rate of non-partitioned column-store tables.
es

27 Record count of column-store table partitions Determines the number of records in the partitions of column-store tables. A table partition cannot contain more than 2,147,483,648 (2 billion) rows.

SQL: "HANA_Configuration_MiniChecks" (SAP Notes 1969700, 1999993) returns a potentially critical issue (C = 'X') for one of the following individual checks:

Check ID Details

M0510 Tables with > 100 partitions

M0512 Hash partitioning on multiple columns

M0513 Tables with many empty partitions

M0515 Partitioned tables with inverted hash indexes

M0519 Tables with large overflow partition

M0520 Tables / partitions > 1.5 billion rows

M0521 Table histories > 1.5 billion rows

M0525 Tables / partitions with large memory size

M0526 Tables / partitions with large memory share

M2020 Partitioned SID tables

M2025 Partitioned special BW tables < 1.5 bill. rows

SQL: "HANA_TraceFiles_MiniChecks" (SAP Note 2380176) reports one of the following check IDs:

Check ID Details

T1100 Inadequate BW partitioning

T2020 Maximum number of rows per partition reached

T2335 No partition available for specific value

T2336 Too low value in dynamic range partition

T3405 No partition available for specific value

T3410 Too low value in dynamic range partition

T3411 Error converting dynamic range partitioning bound

T3415 No dynamic range partitioning in place

SQL: "HANA_Threads_Callstacks_MiniChecks" (SAP Notes 1969700, 2313619) reports one of the following check IDs:
 Check ID Details

C1200 Record move between partitions

C1205 Select count update

C1210 Partition pruning statistics calculation

C1220 Reorg plan precondition check

3. How can I check and evaluate the current partitioning in a system?

Partitioning information can be retrieved in the following ways:
Monitoring views PARTITIONED_TABLES, TABLE_PARTITIONS
SQL: "HANA_Tables_ColumnStore_PartitionedTables" (SAP Note 1969700) to list partitioned tables
SQL: "HANA_Tables_ColumnStore_Partitions" (SAP Note 1969700) to list individual partitions of one or multiple tables
SQL: "HANA_Tables_ColumnStore_TableHostMapping" (SAP Note 1969700) to show the partition distribution of tables across nodes in a scale-out scenario

4. What does partitioning in SAP HANA environments mean?

Partitioning means that tables are split into sub-tables, the so-called partitions, based on defined partitioning criteria.

5. Is partitioning available for both row store and column store?

Partitioning is only available for tables located in the column store. The row store doesn't support partitioning.

6. Is partitioning transparent for the application?

Partitioning is transparent for the application in a way that applications work properly with all partitioning strategies.
Nevertheless partitioning can have an impact on performance, so it can make a difference for the end user and the system load - both in a positive and negative way. In order to minimize the risk of performance regressions it is important to implement a good partitioning strategy.
Moreover, applications may implement special handling for partitions, for example they may add range partitions for upcoming time periods.

7. For what reasons is partitioning required or useful?

In general partitioning is most useful for large tables. In the following situations you can take advantage of partitioning:

Scenario Details

Tables with many reco Each table and partition must not contain more than 2 billion records in the column store. Tables with a risk to reach the 2 billion record limit mid-term should be partitioned.
rds
Be aware that SID tables in BW environments (typically following the naming convention /B%/S% should normally not be partitioned because:

They can never exceed the 2 billion records limit due to BW SID limitations (see SAP Note 1331403).
They typically have 2 unique indexes and so changes would require expensive remote partition checks for uniqueness.

Also other BW attribute tables (typically following the naming convention /B%/H%, /B%/I%, /B%/J%, /B%/K%, /B%/Q%, /B%/T%, /B%/X% and /B%/Y%) should only be considered in special cases, e.g. if the number of records exceeds 1.5 billion and there is a risk to hit the technical lim
it of 2 billion rows.

Check IDs M0520 ("Tables / partitions with many rows"), M0521 ("Table histories with many rows") and M0522 ("Tables / partitions with many UDIV rows") of SQL: "HANA_Configuration_MiniChecks" (SAP Note 1969700) report tables with a particularly high amount of rows (SAP Not
e 1999993).

Tables with large mem Large table / partition sizes in column store are mainly critical with respect to table optimizations like delta merges and optimize compressions (SAP Notes 2057046, 2112604):
ory footprint
Memory requirements are doubled at the time of the table optimization.
There is an increased risk of locking issues during table optimization.
The CPU consumption can be significant, particularly during optimize compression runs.
The I/O write load for savepoints is significant and can lead to trouble like a long critical phase (SAP Note 2100009)

Therefore you should avoid using particularly large tables and partitions and consider a more granular partitioning instead. A reasonable size threshold is typically 50 GB, so it can be useful to use a more granular partitioning in case this limit is exceeded. In cases where it is most important
that the performance isn't impacted by an unnecessarily high number of partitions (e.g. ACDOCA, SAP Note 2289491), it is possible to use a threshold of 100 GB instead.
Be aware that using more partitions doesn't reduce the overall table size. It will only make sure that the size of a single partition is reasonable and can be handled well by table optimizations.

Mini check M0525 ("Tables / partitions with large memory size") reports tables and partitions with a significant memory size (SAP Note 1999993).

Complex queries In scale-out scenarios you can distribute the load of complex requests across different nodes if you locate the table partitions on different hosts. Be aware that this kind of approach can have a negative impact on "simple" queries that also require to access multiple hosts.

Complex queries can also take advantage of parallelism. By processing data in all partitions concurrently the runtime can be reduced significantly.

Tables with hot and w If tables contain frequently accessed (hot) areas and other areas with less frequent accessed (warm) these ranges can be separated by partitioning. The possibility to satisfy a query with accessing only a subset of partitions is also called partition pruning.
arm data
If features like Native Storage Extension (NSE, SAP Note 2799997), data aging (SAP Note 2416490), time selection or paged attributes are used, it is additionally possible to make sure that only a subset of partitions is loaded into memory while partitions containing no hot data remain on d
isk.
 Optimization of table Table optimizations like delta merge (SAP Note 2057046) or optimize compression runs (SAP Note 2112604) can be improved by proper partitioning. Positive effects can be:
optimizations
Creating more partitions reduced the table optimization data volume and runtime because table optimizations happen on partition level and not globally. Quicker optimizations can have various benefits (e.g. less locking of concurrent activities and earlier reduction of delta storage ove
rhead).
If tables can be partitioned so that changes happen only to a subset of partitions, table optimizations are performed more targeted and unchanged partitions don't need to be touched.

NUMA optimization Expensive queries related to specific large tables can result in an overload on certain NUMA nodes and effects like the following are possible:

Performance regression due to increased number of queued JobWorkers that need to run on the overloaded NUMA node
Performance regression and increased CPU consumption due to execution of expensive queries on remote NUMA nodes

By creating more partitions the table is typically split across several NUMA nodes and so the risk of local overloads is reduced. Starting with SAP HANA 2.0 SPS 03 you can explicitly assign a partition to a NUMA node using the NUMA NODE clause.

See SAP Note 2470289 for more information related to non-nuniform memory access (NUMA) in SAP HANA environments.

Log replay performanc Log replay can happen in different contexts, e.g.:
e
System replication (SAP Note 1999880) with logreplay / logreplay_readaccess operation mode
SAP HANA restart (SAP Note 2222217)
SAP HANA recovery
System replication takeover

Log replay of one table (partition) is performed sequentially without the possibility to parallelize. So if you have tables that are very frequently changed and so a lot of redo information is generated, these tables can be the deciding factor for log replay performance and it can also be responsi
ble for a system replication log replay backlog.

Setting up more and smaller partitions for a heavily modified table can improve the performance and reduce the backlog of log replay operations.

Delta storage contenti Contention on delta storage (SAP Note 1999998, Sleeping / Sleep Semaphore / BTree GuardContainer) can be reduced by setting up more partitions.
on
The same applies to delta append rollovers (SAP Note 1999998, DeltaDataObjectAppendRollover).

Explicit partition hand In some cases it can be useful that the application controls the creation and existence of partitions based on specific criteria.
ling

8. What kind of problems can be introduced with partitioning?

The following potential problems should be considered before implementing partitioning. The actual impact depends on the implementation, so with a good preparation you can minimize overhead and risks.

Problem SAP Details

Note

Memory overhead 1999 The collection and merging of data from different partitions can increase the memory requirements of SQL statements.
997

Transactional deadlock 1999 Bulk modifications on partitioned tables don't guarantee the specified order of the records and so there is an increased risk of transactional deadlocks ("SQL error 133: transaction rolled back by detected deadlock").
s 998

Increased CPU consum 2000 For various reason the CPU consumption can increase. See SAP Note 2000002 ("What are typical approaches to tune expensive SQL statements?" -> "Execution time higher than expected, negative impact by existing partitioning") for more information.
ption 002
Performance regression 2100
s 040

Increased scale-out net 2222 Partitioning typically increases the inter-node network traffic in scale-out environments.
work traffic 200

Risk of inconsistencies i 2436 Partitioning in context of inverted hash indexes (SAP Note 2109355) can result in inconsistencies with certain SAP HANA Revision levels.
n case of inverted hash i 619
ndexes

Increased dictionaries a 1998 Joining partitioned tables can result in a high amount of translation tables because in the worst case every partition of the first table has to be joined with every partition of the second table and each join is based on a individual translation table. So more partitions can result in mor
nd translation tables 599 e translation tables.

If partitioning distributes identical column values of columns with a rather high amount of distinct values to different partitions, these values need to be included into several (partition-level dictionaries) and so the overall dictionary size increases. As a consequence also translation
table sizes increase when the column is joined.

LOB cleanup overhead 2220 Both standard and online partitioning will result in a recreation of all LOBs. The disk LOBs of the original table are dropped at the time when the original table is dropped. This can result in significant LOB garbage collection and persistence garbage collection overhead (SAP Note
627 2169283) after tables with many disk LOBs were partitioned. The cleanup puts the system at risk of performance issues, e.g. due to LOBFileIdMapping contention during persistence garbage collection (SAP Note 1999998). Thus, avoid partitioning tables with a significant amount
of LOBs whenever possible. See Minimize partitioning when many disk LOBs are present for more information.

9. Which partitioning types exist?

The following partitioning types exist in SAP HANA environments:
 Partitioning t Details Advantages Disadvantages / Restrictions
ype

HASH Records are assigned to partitions based on a hash algorithm on the partition key columns Easy setup All partitions need to be scanned unless all partition key columns are specified with "=" or "IN" conditions in the WHERE c
lause.
No maintenance required
Need to be based on primary key columns (if primary key exists, for first-level partitioning, homogeneous partitioning)
Rather even row distribution if partition keys are selective without frequent
values No logical separation of data (e.g. hot vs. cold) possible

ROUNDROBIN Records are assigned in a round-robin manner to the available partitions, partition key col Easy setup All partitions need to be scanned, no partition pruning possible
umns are not required
No maintenance required No logical separation of data (e.g. hot vs. cold) possible

Even row distribution No primary key allowed (because overhead of constraint evaluation would be significant)

RANGE Records are assigned to partitions using defined (non-overlapping) partition ranges Setup of optimal ranges requires application knowledge
Allows application related separation of data into different partitions (e.g. ho Regular maintenance required (e.g. definition of new partitions for upcoming year in case of time-based ranges, deletion of
t vs. cold) old partitions after archiving)

Consequently the best way to take advantage of partition pruning and delta Potentially uneven row distribution
merge optimization
Need to be based on primary key columns (if primary key exists, first-level partitioning, homogeneous partitioning)

10. Is LIST partitioning available?

LIST partitioning allows to assign single or multiple values to a single partition. As part of RANGE partitioning SAP HANA allows to assign a single value to a single partition, but it is not possible to assign multiple values to a single partition. A dedicated LIST partitioning option is not
available.

11. What is single-level and multi-level partitioning?

If a table is partitioned exclusively by one of the above partitioning approaches (HASH, ROUNDROBIN, RANGE), it is called single-level partitioning.
If each of the partitions itself is partitioned again by other criteria, we call it multi-level partitioning. In the following picture you can see a multi-level partitioning with a HASH partitioning on level 1 and a RANGE partitioning on level 2:

The total number of partitions is the product of the number of partitions on every level.
The partition key columns of the second level can be chosen independent of the primary key of the table in case of HASH / HASH and RANGE / HASH partitioning.
The partitions on the second level form so-called partition groups (in the example above partitions 1 and 2 are one partition group, partitions 3 and 4 are another partition group). All members of a partition group are always located on the same node and can only be moved as a unit.

12. Are locks involved when a table is partitioned?

With SAP HANA 1.0 the standard table (re-)partitioning sets an exclusive object lock (see SAP Note 1999998), so all modifying DML operations are blocked while the partitioning is performed. SELECTs are still possible without any restriction.
Starting with SAP HANA 2.0 SPS 01 table (re-)partitioning is also available as online operation (key word ONLINE) that doesn't permanently set the exclusive object lock and only requires it for synchronization reasons at the beginning and the end of the activity. Other potential side effects
like high resource consumption or internal lock contention (e.g. ConsistentChangeLock) are still possible, though. To minimize locking times and other issues you should consider the following aspects:
Avoid large delta storages before starting the partitioning (e.g. by manually executing a delta merge, SAP Note 2057046).
Execute the partitioning at a time when there is limited modification load on the underlying table. Otherwise the delta storage can grow significantly during the partitioning and the final locking phase can increase.
SAP Note 2873607 describes potential problems with SAP HANA <= 2.00.048.01 when table replication is used (SAP Note 2340450) or partitioning is started concurrently for different tables.

13. Which best practices exist for partitioning tables?

The following general best practices exist for partitioning tables:

Rule Details

As few partitioned tables as possible Only partition tables if you see a clear benefit without significant regressions. Consider at first other options like data management and archiving (SAP Note 2388483), transition to inverted individual indexes (SAP Note 2600076), reduction of index
es and concat attributes or transition from VARBINARY to LOB (SAP Note 2375917) in order to resolve size and record related partitioning demands.
 As few partitions as possible An unnecessary high amount of partitions results in overhead because some queries may have to access all partitions to find the data:

A high amount of network channels are opened and so the system is at risk to reach the maxchannels limitation (SAP Note 2222200) and run into network related terminations.
Certain operations like the determination of column statistics ("getColumnStat", SAP Note 2114710) have to be performed individually for each partition.

So consider the following general rules before defining a certain number of partitions:

If you partition tables due to the 2 billion limit it is usually acceptable if individual partitions contain up to 1.5 billion records (less if you expect a significant future growth).
If you partition by date, you should avoid using granular ranges (e.g. days or weeks) resulting in a high amount of partitions.
If you use range partition on columns with data that is not evenly distributed (e.g. number range column with multiple different number ranges), you should check the actual value distribution and define the range limits accordingly.

As few empty partitions as possible The existence of many empty partitions can confuse the SAP HANA optimizer. See check ID M0513 of the SAP HANA Mini Checks (SAP Note 1999993) and make sure that you don't have a dominating amount of empty partitions. For example, don't
perform time based range partitioning for ten years in the future and instead extend the partitions on a regular basis for the subsequent years.

As few partition key columns as possible It is often useful to keep the number of partition key columns at a minimum extent because:

Partition pruning of HASH partitions can only be used if all underlying partitioning columns are specified with "=" or "IN" in the WHERE clause.
Partition columns like CLIENT that are specified both with "=" and used in a join aren't considered for partition-wise grouping operations (due to grouping simplification), so expensive global grouping / distinct operations can happen.
Determining partition pruning can be quite time consuming if many partition keys are involved. See SAP Note 2000002 ("What are typical approaches to tune expensive SQL statements?" -> "Execution time higher than expected, negative imp
act by existing partitioning") for more details.
Updating a column that is used for partitioning imposes the possibility of a partition move and significant overhead is possible in this context, see e.g. SAP Note 2100040 ("How can CPU intensive operations in SAP HANA be identified and opti
mized?" -> "TrexStore::UdivListManager::getEqualSSNUdivs"). A reduced number of partition columns reduces the risk of this scenario.

In case of HASH partitioning it is often useful to use only the most selective primary key column as partition key column.

SAP SoH / S/4HANA: All partitions on same host In scale-out Suite on HANA environments it is typically of advantage to keep all partitions of a table on the same host. As of SPS 08 this can be achieved with an appropriate table placement configuration.

As a fallback option you can use a dummy first level partitioning (e.g. on MANDT) and perform the actual partitioning on the second level. In this case all partitions will be located on the same host.

HASH partitioning: Selective partitioning column(s) without po When using HASH partitioning it is usually intended to distribute the columns as evenly to the partitions as possible. Due to the nature of the hash algorithm all records with the same hash partitioning column value go to the same partition. In order
pular values to maintain an even distribution of records to partitions the following rules should be considered when choosing the partitioning column(s):

No highly popular values: If e.g. 50 % of all records have the same value in the partitioning column(s), these 50 % of records will use the same partition - regardless how many partitions are defined.
Many distinct values: If only a few distinct values exist, there is no guarantee that each distinct value is mapped to a different partitios. It is possible that several values are mapped to the same partition and so this partition can become quite lar
ge.

See Are there specific partitioning recommendations for certain SAP applications and tables? for standard HASH partitioning recommendations on large SAP tables fulfilling these rules.

Repartitioning: Choose new number of partitions as multiple / If a table is already partitioned it is most efficient to choose a new number of partitions that is a factor 2 multiple or divider of the current number of partitions (e.g. 4 --> 8 or 6 --> 3 partitions), because only in this case the repartitioning can happen
divider of current number of partitions in parallel on different partition groups and hosts (“parallel split / merge”).

No additional unique constraints Avoid partitioning tables with additional unique constraints (e.g. unique secondary index), because the uniqueness checks impose a significant overhead.

Minimize partitioning when many disk LOBs are present The existence of many disk LOBs (SAP Note 2220627) can have negative effects:

The partitioning runtime can be significantly increased. See check ID C1225 ("LOB copy") of SQL: "HANA_Threads_Callstacks_MiniChecks" (SAP Note 1969700) described in SAP Note 2313619 for details.
After the partitioning operation the cleanup of the old disk LOBs can take significant time and introduce lock contention. See LOB cleanup overhead for details.

Thus, you should be careful with partitioning tables with many disk LOBs (e.g. more than 50 million) and optimally test both the partitioning performance and the subsequent LOB cleanup effects.

SAP Note 2000002 -> "What are typical approaches to tune expensive SQL statements?" -> "Execution time higher than expected, negative impact by existing partitioning" describes symptoms that can be introduced by inadequate partitioning.

14. How can partitioning changes be implemented?

In BW environments partitioning is typically automatized and no manual partitioning is required. See SAP Note 2143736 for more information.
In other environments you can use table distribution as described in SAP Note 2081591.
In SLT scenarios you can define the partitioning scheme for new tables via transaction LTRS -> Table Settings -> Partition Command (SAP Note 2528241).
Alternatively it is possible to use individual SQL statements. The table below contains some important examples. For further details check the SAP HANA SQL Reference.

Activity Example command

Create a table with HASH partitioning CREATE COLUMN TABLE ... PARTITION BY HASH (<column1>, ..., <columnN>) PARTITIONS <num_partitions>

Create a table with ROUNDROBIN partitioning CREATE COLUMN TABLE ... PARTITION BY ROUNDROBIN PARTITIONS <num_partitions>

Create a table with RANGE partitioning CREATE COLUMN TABLE ... PARTITION BY RANGE (<column1>)
( PARTITION 1 <= VALUES < 100,
PARTITION 100 <= VALUES < 200,
PARTITION VALUE = 400,
PARTITION OTHERS )
 Create a table with multi-level HASH / RANGE partitioning CREATE COLUMN TABLE ... PARTITION BY HASH (<column1>, <column2>) PARTITIONS <num_partitions>,
RANGE (<column3>)
( PARTITION 1 <= VALUES < 5,
PARTITION 5 <= VALUES < 20 )

Add a new RANGE partition ALTER TABLE ... ADD PARTITION 200 <= VALUE < 300

Drop an existing RANGE partition ALTER TABLE ... DROP PARTITION 100 <= VALUE < 200

Move a partition to a different host ALTER TABLE ... MOVE PARTITION <partition> TO '<host>:<port>'

Adjust partitioning of an already existing table ALTER TABLE ... PARTITION BY ...

Transfer a partitioned table in a non-partitioned table ALTER TABLE ... MERGE PARTITIONS

Tables partitioned by applications for aging (time selection partitioning) cannot be re-partitioned or converted to a non-partitioned table ("If a table is partitioned with Time Selection, it is not allowed to repartition it to anything") prior to SAP HANA 2 SPS3. This is a limitation caused by the
non-enforced constraint checks on historical partitions. New re-partitioning/converting options are offered from SAP HANA 2 SPS3 onwards (SAP Note 2416490).

15. How can the consistency of partitions be checked?

The consistency of partitions, which e.g. includes the correct assignment of records to partitions, can be checked with the following CHECK_TABLE_CONSISTENCY options:
CHECK_PARTITIONING
CHECK_PARTITIONING_DATA
In order to make sure that the both the initial state and the results of a partitioning activity is consistent, you can activate an implicit consistency check with the following parameter with SAP HANA >= 2.0 SPS 05:

indexserver.ini -> [table_consistency_check] -> check_repartitioning_consistency = true

See SAP Notes 1977584 and 2116157 for more information related to SAP HANA consistency checks.

16. Is it possible to truncate a partition?

Up to SAP HANA 2.0 SPS 05, it is not possible to use a TRUNCATE operation on partition level. Starting with SAP HANA 2.0 SPS 06 it is possible to by specifying a list of partitions to be truncated.
Example: (truncation of partition IDs 2 and 3 of table ZMF_PART)

TRUNCATE TABLE ZMF_PART PARTITION (2, 3)

See "How can database requests be restricted to a subset of partitions of a table?" for more information.

17. How should tables be partitioned in BW environments?

BW takes care of the partitioning of its tables on its own, manual intervention is usually not required. You mainly have to take care that the table placement configuration is maintained properly (SAP Notes 1908075 and 2334091). Table distribution (SAP Note 2143736) will then implement the
configuration.
The number of first level partitions depends on number of records in the largest table of the table group respectively the TABLE_PLACEMENT configuration. Default scenario:

Records Partitions

< 40 million 1

40 - 120 million 3

120 - 240 million 6

> 240 million 12

The following table provides an overview how tables are typically partitioned in BW environments. <bw_prefix> is a place-holder for BW related table prefixes like "BIC" (customer namespace), "BI0" (SAP namespace) or other prefixes defined in table RSNSPACE.

Object type Object detail Table name First level partitioning Second level partit SAP Details
ioning Note

advanced DSO inbound queue /<bw_prefix>/A HASH <semantic_key> RANGE [DYNAMIC] 20811 Dynamic range partitioning can be used for the inbound queues of advanced DSOs. See Is there a way to automatize the creation of new range partitions? for more information.
<dso_name>1 REQTSN 35
2374
652

advanced DSO active data /<bw_prefix>/A HASH <semantic_key> optional: RANGE <us 20811 See SAP BW on HANA - Creating DSO Partitions and SAP BW/4HANA - Creating DSO Partitions for more details.
<dso_name>2 er_defined_fields> 35
2374
652
advanced DSO change log /<bw_prefix>/A HASH <semantic_key> RANGE [DYNAMIC] 20811 Dynamic range partitioning can be used for the change logs of advanced DSOs. See Is there a way to automatize the creation of new range partitions? for more information.
<dso_name>3 REQTSN 35
2374
652

advanced DSO validity table /<bw_prefix>/A HASH REQTSN, <optiona 20811

<dso_name>4 l_validity_characteristics 35
> 2374
652

advanced DSO reference points /<bw_prefix>/A HASH <semantic_key> optional: RANGE <us 20811
<dso_name>5 er_defined_fields> 35
2374
652

standard DSO active data /<bw_prefix>/A HASH <semantic_key> optional: RANGE [FI 1908 Second level range partitioning is optional and either done on FISCPER or on CALMONTH.
<dso_name>00 SCPER | CALMONTH 075
] 2334
091

standard DSO activation queue /<bw_prefix>/A HASH <semantic_key> 1908

<dso_name>40 075
2334
091

standard DSO change log /<bw_prefix>/B HASH REQUEST, DATAP optional: RANGE PA 17678 PSA tables and standard DSO change log tables share the naming convention and structure.
* AKID, RECORD RTNO 80
20811
35

write-optimized DSO 'Allow duplicate da /<bw_prefix>/A HASH REQUEST, DATAP optional: RANGE PA 17678 With NetWeaver <= 7.30 (7) different partitioning approaches were used.
ta records' = TRUE <dso_name>00 AKID, PARTNO RTNO 80

write-optimized DSO 'Allow duplicate da /<bw_prefix>/A HASH <semantic_key> 17678 With NetWeaver <= 7.30 (7) different partitioning approaches were used.
ta records' = FALS <dso_name>00 80
E

PSA PSA /<bw_prefix>/B HASH REQUEST, DATAP optional: RANGE PA 17678 PSA tables and standard DSO change log tables share the naming convention and structure.
* AKID, RECORD RTNO 80
20811
35

dimension tables /<bw_prefix>/ In case of dimension tables with a high number of records you can consider the transition to a line item dimension so that the SIDs are directly joined rather than being part of a di
D* mension table.

classic E fact tables compressed /<bw_prefix>/E ROUNDROBIN RANGE KEY_<infocu 1908 In each first-level partition three second-level RANGE partitions are defined on the KEY_<infocube>P which refers to different types of fact table data:
<cube_name> be>P, <dimids> 075
Compressed requests
2334
091 Reference points

Historic movements

classic F fact tables uncompressed /<bw_prefix>/F ROUNDROBIN 1908

<cube_name> 075
2334
091

flat / in-memory optimized / combined /<bw_prefix>/F ROUNDROBIN RANGE KEY_<infocu 1908 In each first-level partition four second-level RANGE partitions are defined on the KEY_<infocube>P which refers to different types of fact table data:
HANA optimized F fact table <cube_name> be>P, <dimids> 075
1st range partition: Compressed requests (Compressed deltas)
s 2334
091 2nd range partition: Reference points (Initialization records)

3rd range partition: Historic movements (Historic transactions)

4th range partition: Uncompressed requests (Uncompressed requests)

See SAP Note 1548125 -> "HANA Optimized Inventory Cubes" for more details.
 InfoObjects SID table /<bw_prefix>/S 13314 Generally avoid partitioning SID tables (/BI0/S*, /BIC/S*) because the combination of partitioning, two unique indexes and the particular change load can result in problems due
* 03 to uniqueness checks (thread method "CheckRemoteUniqueConstraint", see SAP Note 2114710). See SAP Notes 1331403 and 2019973 for managing large SID tables from a BW pe
rspective.

InfoObjects other tables /<bw_prefix>/ 20199 These tables aren't partitioned per default and should only be partitioned in rare cases when there is a risk that the 2 billion record limit is reached. In that case consider remodelin
H* 73 g the scenario or InfoObjects with high cardinality.
/<bw_prefix>/I
*
/<bw_prefix>/J
*
/<bw_prefix>/K
*
/<bw_prefix>/P
*
/<bw_prefix>/Q
*
/<bw_prefix>/T
*
/<bw_prefix>/X
*
/<bw_prefix>/Y
*

InfoObjects with high cardin time-independent /<bw_prefix>/P HASH <InfoObject>, OBJ 20199 For InfoObjects with high cardinality, P-, Q- and T-table are partitioned by default.
ality attributes * VERS 73

InfoObjects with high cardin time dependent att /<bw_prefix>/Q HASH <InfoObject>, OBJ 20199 For InfoObjects with high cardinality, P-, Q- and T-table are partitioned by default.
ality ributes * VERS, DATETO 73

InfoObjects with high cardin master data texts /<bw_prefix>/T HASH <InfoObject>, LAN 20199 For InfoObjects with high cardinality, P-, Q- and T-table are partitioned by default.
ality * GU, DATETO 73
DATETO is part of the partition specification if time-dependent texts are used.

In addition to the above database partitioning BW also provides the option for semantic partitioning. This is based on different tables with the same structure, but it doesn't involve partitioning on SAP HANA level.

18. Is the partitioning information kept during homogeneous SAP HANA system copies?
If the homogeneous system copy is performed using backup and restore the partitioning information is kept.
A system copy based on R3load doesn't copy the partitioning information per default. If you want to keep it you have to use the SMIGR_CREATE_DDL report.

19. Is the partitioning information kept during transports?

Partitioning information is not available in ABAP DDIC. Therefore transports don't consider it and partitioning is not transported. This means that you have to activate partitioning in all involved systems of your ABAP system landscape individually.

20. Is the partitioning information kept during ABAP table conversions and SAP upgrades?
Partitioning information is kept when a table conversion in SAP ABAP is performed and when a SAP upgrade is performed.

21. My table has a partition specification, but it shows only PART_ID 0 in M_CS_TABLES. Is this correct?
Tables partitioned with HASH or ROUNDROBIN and only one partition are non-partitioned tables which have a partition specification.

22. Where can I see which partitions are loaded into memory?
This information is available in column LOADED of monitoring view M_CS_TABLES:

LOADED Description

NO No column of partition is loaded into memory

PARTIALLY Some columns of partition are loaded into memory

FULL Partition is completely loaded into memory

SQL: "HANA_Tables_Partitions" (SAP Note 1969700) can be used to display the LOADED state and other partition details.

23. Is it possible to load a single partition only?

No. The load and preload operations consider all partitions of a table (exception: see next question).

24. Are cold partitions for aging and time-selection tables pre-loaded?
As of SAP HANA 1.0 SPS 09, load and pre-load do not consider cold partitions.
25. How many partitions are allowed for one table?
There is a maximum of 1000 (SPS <= 09) or 16000 (SPS >= 10) partitions for one table. For multi-level partitioning, multiply the number of first-level partitions with the number of second-level partitions to get the total number of partitions. This maximum number for one table is
independent of the table location in a scale-out landscape.

26. Which data types are allowed for partitioning columns?

The supported data types are listed in the Partitioning Limits section of the SAP HANA Administration Guide.
Partitioning is not supported for columns defined with GENERATED ALWAYS and for concat attribute columns (SAP Note 1986747).

27. Are there specific partitioning recommendations for certain SAP applications and tables?
For the standard approach (typically HASH partitioning on a selective column being part of the primary key), the following partitioning recommendations can be used. Typically this partitioning layout is a good compromise between efforts and results for smaller tables. For larger data volumes
you can check further below for application related recommendations.
The number of partitions depends on the reason for partitioning (e.g. reducing data footprint per partition, reducing records per partition).
Be aware that for tables making use of Data Aging (SAP Note 2416490) or NSE (SAP Note 2799997) there are certain limitations related to partitioning and so the simple standard approach isn't possible.

Table Type Columns

/1CADMC/<id> HASH IUUC_SEQUENCE

ACDOCA HASH BELNR

(if data volume is limited, otherwise see SAP Note 2289491)

ACCTIT HASH AWREF

ADRC, ADRU HASH ADDRNUMBER

AFFV HASH AUFPL

AUSP HASH OBJEK

BALDAT HASH LOG_HANDLE

BDCP2 HASH CPIDENT

BDSCONT10, DMS_CONT1_CD1, SBCMCONT1 HASH PHIO_ID

BKPF, BSEG, BSIS HASH BELNR

CDHDR, CDPOS HASH OBJECTID, CHANGENR or TABKEY

(use column with best value distribution and use same column for both tables if possible, in some cases OBJECTID for CDHDR and CHANGENR for
CDPOS can be the best solution)

CDPOS_UID HASH KEYGUID

CE1<operating_concern>, CE4<operating_concern>, CE4<operating_concern>_ACCT HASH PAOBJNR

e.g.: CE11000, CE41000_ACCT, CE4A001_ACCT, CE4HI01, CE4HI01_ACCT

CIFBALSEL HASH LOGNUMBER

CKMLCR, CKMLKEPH HASH KALNR

CLF_OBJKEY_MPPNG HASH CLFOBJKEY

COBK, COEP HASH BELNR

COFV HASH CRID

COKA, COSB HASH OBJNR

CRM_JEST, CRM_JSTO HASH OBJNR

CRMM_PRSALESH HASH VALID_TO

DBERCHZ<id> HASH BELNR

DBERDL, DBERDLB HASH PRINTDOC

DBTABLOG HASH LOGID

DBVM HASH MATNR

 DFKKCODCLUST HASH COKEY

DFKKKO, DFKKOP, DFKKOPK, DFKKOPW, DFKKZR HASH OPBEL

DFKKOPBW HASH RECNO

DFKKPOP HASH PYORD

DIMAPARSCPOS HASH POSNR

/DOC/D_TC_TEXT_CNT HASH NODE_ID

DPAYP HASH PAYNO

DSVASRESULTSGEN HASH SESSNO

EDID4, EDIDS HASH DOCNUM

EIPO HASH EXNUM

EKBE HASH BELNR

EKPO HASH EBELN

EMMA_JOBRUNIDMSG HASH SRTFD

EPROFVAL<id> RANG VALUEDAY

E

EPROFVERSVALUE RANG PROFVERSNO

E

EQKT HASH EQUNR

FAGLFLEXA HASH DOCNR

FAGL_SPLINFO, FAGL_SPLINFO_VAL HASH BELNR

(if data volume is limited, otherwise see SAP Note 2289491)

FARR_D_MAPPING_I HASH SRCDOC_ID

FARR_D_POSTING HASH POB_ID

FKKMAZE HASH OPBEL

FOT_RECON HASH UUID

FPLT HASH FPLNR

FQM_FLOW HASH FLOW_ID

GLFUNCA, GLPCA HASH GL_SIRID

IBINVALUES HASH IN_RECNO

ICLACTIVITY, ICLITEM, ICLITEMEV, ICLPARTOCC, ICLPAYI, ICLPROCURE, ICSACTIVITY, ICSCLAIM, ICSITEMEV, ICSPAYI, ICSPROCURE, ICSS HASH CLAIM
UBCL

IDOCREL HASH ROLE_A or ROLE_B

(column with better value distribution)

INDX HASH SRTFD

JCDS, JEST HASH OBJNR

JVTLFZUO HASH VBELN

KEPH HASH KALNR

 KONV HASH KNUMV

KSSK HASH OBJEK

/LIME/NLOG_QUAN HASH GUID_STOCK

/LIME/NLOG_TREE HASH GUID

LIPS HASH VBELN

LOYD_MA_GENATTR, LOYD_MA_SPECATTR, LOYD_MSH_MEMS HASH GUID

MARDH HASH MATNR

MATDOC HASH MBLNR

MBEW, MBEWH, MVER, MYMFT HASH MATNR

MLAUF, MLAUFCR, MLAUFCRLD, MLAUFKEPH, MLAUFKEPHLD, MLBE, MLBECR, MLBECRLD HASH MLVNR

MLCR, MLCRF, MLCRFLD, MLCRLD, MLCRP, MLCRPLD, MLHD, MLIT, MLKEPH, MLKEPHLD, MLMST, MLPP, MLPPF, MLPRKEKO, MLPRKEKO HASH BELNR
LD, MLPRKEPH, MLPRKEPHLD

MLDOC, MLDOCCCS HASH DOCREF

MSEG HASH MBLNR

NAST HASH OBJKY

OBJK HASH OBKNR

P2RU_TRCT, P2RX_CRT, P2RX_RT HASH DCT_PERNR

PCL2, PCL4 HASH SRTFD

POC_DB_VALUE HASH OS_GUID

/POSDW/PLOG1S HASH GUID

PPOIX, PPOPX HASH PERNR

PRCD_ELEMENTS HASH KNUMV

REGUP HASH BELNR

RESB HASH RSNUM

RSBATCHDATA HASH TIMESTAMP

RSBKSELECT, RSBMLOGPAR_DTP, RSBMONMESS_DTP, RSBMREQ_DTP HASH REQUID

RSDDSTATDTP HASH INSTANCE

RSEG HASH BELNR

RSHIENODETMP, RSMONMESS, RSSTATMANREQMDEL HASH RNR

RSODSACTUPDTYPE HASH REQUEST

RSRWBSTORE HASH WORKBOOKID

S027, S827 HASH MATNR

S033 HASH MBLNR

 SBCMCONT1 HASH PHIO_ID

/SCDL/DB_REFDOC HASH REFDOCID

/SCDL/DB_STATUS HASH DOCID

SLPE_RT_PLOG HASH LOG_ID

SOC3 HASH SRTFD

SRAL_EXP_DATA HASH LOG_ID

SRRELROLES HASH OBJKEY

SRTMP_DATA HASH SUBID

/SSF/BTAB HASH OBJKEY

/STTP/SNR_LIST HASH SERNO

STXL HASH TDNAME

SWFRCNTXML HASH GUID

SWFREVTLOG HASH LOGGUID

SWPNODELOG HASH WF_ID

SWWCNTP0, SWWLOGHIST HASH WI_ID

T0A01 HASH ARC_DOC_ID

UDMBPSEGMENTS HASH PARTNER

UDM_WL_ITEM_D HASH WORKITEM_ID

VBFA HASH SoH: HASH (VBELV), S/4HANA: HASH (RUUID)

VBKPA HASH KUNDE

VBOX HASH VAKEY

VAPMA, VBAP, VBPA, VBUP HASH VBELN

VBSK HASH SAMMG

VEKP, VEPO HASH VENUM

VVSCITEM, VVSCPOS HASH POSNR

WLK1 HASH ARTNR

In addition the following SAP Notes contain suggestions for partitioning specific SAP application tables. Particularly for higher data volumes using the approaches described in these SAP Notes should be preferred:

SAP Applicatio Tables

Note n

17192 SAP Point of /POSDW/TLOGF, /POSDW/TLOGF_EXT

82 Sale (POS)
SAP Custom
er Activity R
epository (C
AR)
2190 SAP Unified /DMF/LANE, /DMF/LANE_PRC, /DMF/LANE_TD, /DMF/OFR_FIN_DTL, /DMF/OFR_PL, /DMF/PRDLOCEXTXR, /DMF/PRODLOC, /DMF/PRODLOC_PRC, /DMF/PRODLOC_TD, /DMF/TS_INV, /DMF/TS_PS, /DMF/TS_UN, /DMF/UFC_TSD, /DMF/UMD_TSD, /DMF/UMD_
377 ( Demand For PAR_COV, /DMF/UMD_TS, /DMF/UMD_PAR, /DMF/UMD_PRI, /DMF/UMD_MET, /DMF/UTASK_CONT
singl ecast (UDF)
e nod SAP Deman
e) d Data Foun
2700 dation(DDF)
982 (
scale-
out)

3051 SAP Repleni /DMF/OP4A_HOREND, /DMF/OP4A_ITM, /DMF/OP4A_TRCITM, /DMF/OP4A_TRCMVT, /DMF/OP4A_TRCOPI, /DMF/OP4A_TRCRUN, /DMF/OP4A_TRCTD, /DMF/OP_HOREND, /DMF/OPLN_TRCITM, /DMF/OPLN_TRCMVT, /DMF/OPLN_TRCOPI, /DMF/OPLN_TRCRU
343 shment Plan N, /DMF/OPLN_TRCTD, /DMF/ORDPLN_ITM, /DMF/PO_ITM_GDR, /DMF/PO_ITM_SCHD, /DMF/PRC, /XRP/REPL_KPI_TS
ning

2259 S/4HANA m MATDOC

038 aterial mana
gement

2289 SoH / S/4H ACCTCR, ACCTHD, ACCTIT, ACDOCA, BSEG, BSAS, BSIS
491 ANA finance
3325 tables
787

2524 Bank Analyz /BA1/BR_REG_AD, /BA1/BR_REG_BT, /BA1/BR_REG_MD, /BA1/FC_PCDSTATF, /BA1/FC_REGSTAT, /BA1/F1_CON_FLAT, /BA1/F1_*_FLAT, /BA1/F2_BT_FLAT, /1BA/HM_*
869 er / Smart A
FI

2546 Revenue Acc FARR_D_DEFITEM, FARR_D_FULFILLMT, FARR_D_POSTING, FARR_D_RECON_KEY

640 ounting and
Reporting

2722 S/4HANA Fi /BA1/F1_BPR_FLAT, /BA1/F1_CFH_FLAT, /BA1/F1_CON_FLAT, /BA1/F1_CRL_FLAT, /BA1/F1_CTN_FLAT, /BA1/F1_FCC_FLAT, /BA1/F1_FCD_FLAT, /BA1/F1_KFG_FLAT, /BA1/F1_LIM_FLAT, /BA1/F1_OPD_FLAT, /BA1/F1_OPE_FLAT, /BA1/F1_OPF_FLAT, /BA1/F1_OPH_F
355 nance Produ LAT, /BA1/F1_RCH_FLAT, /BA1/F1_RRC_FLAT, /BA1/F2_BT_FLAT, /BA1/HFGPD, /BA1/HFPPD, /BA1/HFSPD, /BA1/HKAAS, /BA1/HKACG, /BA1/HKAMS, /BA1/HKANA, /BA1/HKAPA, /BA1/HKAPD, /BA1/HKCDA, /BA1/HKCFO, /BA1/HKCFR, /BA1/HKCOR, /BA1/HKEAS, /BA1
cts Subledge /HKEPR, /BA1/HKEPS, /BA1/HKETV, /BA1/HKIMT, /BA1/HKLFP, /BA1/HKLSE, /BA1/HKMES, /BA1/HKPAI, /BA1/HKPAP, /BA1/HKPAT, /BA1/HKPGD, /BA1/HKRIC, /BA1/HKRMC, /BA1/HKRPE, /BA1/HKRPS, /BA1/HKTVL, /BA1/HKTVR, /BA1/HKULT, /BA1/HKVEC, /BA1/HK
r VOL, /BA1/HSAAS, /BA1/HSACG, /BA1/HSAMS, /BA1/HSANA, /BA1/HSAPA, /BA1/HSAPD, /BA1/HSCDA, /BA1/HSEAS, /BA1/HSEPR, /BA1/HSEPS, /BA1/HSETV, /BA1/HSLFP, /BA1/HSMES, /BA1/HSPAI, /BA1/HSPAP, /BA1/HSPAT, /BA1/HSRIC, /BA1/HSRMC, /BA1/HSRPE, /B
A1/HSRPS, /BA1/HSSPD, /BA1/HSULT, /BA1/HSVEC, /BA1/HSVOL, /BA1/DT_EOPR_WL, /BA1/HKCBD, /BA1/HKCBD_EBA, /BA1/BR_REG_BT, /BA1/BR_REG_MD, /BA1/BR_REG_MDC, /BA1/BR_REG_AD, /BA1/FC_PCDSTAT, /BA1/FC_REGCAP, /BA1/FC_MATCH_SR, /BA1/
BR_REG_BPC, /BA1/BR_CAP_BECF

2845 Material Led CKMLCR

463 ger

2849 Transaction /FSFAC/RES_XL, /FSFAC/RLOG_XL, /FSFAC/ULOG_XL, /FSFAC/UTIL_XL, BCA92, BCA92_RESTART, BCA96, BCA98, BCASO_PAORN, BCA_ACCTBAL, BCA_ACCTBAL_FP, BCA_BANO_DUE, BCA_BCAS_DUE, BCA_BCT_CN_OBJV, BCA_BL_SCHED, BCA_BL_SCHED_H, BC
678 al Banking A_CAP_KDATE, BCA_CARD_HEADER, BCA_CNFW_EVENT, BCA_CNSP_ACCT, BCA_CN_EVENT, BCA_CN_LINK, BCA_CN_PER_ACBAL, BCA_CN_SL_DATA, BCA_CN_TDLK, BCA_CONTRACT, BCA_COUNTER, BCA_GL_BALCN, BCA_GL_BPITEM, BCA_GL_BSPR_PROT, B
CA_GL_PAYMITEM, BCA_GL_SNITEM, BCA_GL_TRNTP, BCA_INV_DETAILS, BCA_NOW_ABS, BCA_PAYMITEM, BCA_PAYMITEM_NT, BCA_PO_IT, BCA_PO_NT, BCA_PRENOTE, BCA_SB_2BR, BCA_SB_2BR_CHNG, BCA_SNITEM, BCA_TRANSFIG, BCA_TRNOVER, BKK9
2_POSTINGS, BKK92_SIM, BKK92_SUMS, BKK92_SUMS_SIM, BKK96_SIM, BKKSOHD, BKKSOIT, BKKSOITNT, BKKSOIT_VAR_AMNT

31391 Material Led MLDOC, MLDOCCCS

40 ger - Actual
Costing

2014 SLT logging /1CADMC/<id>

562 tables

3301 Production a /PRA/ACCT_DOC, /PRA/MKT_DOC, /PRA/TAX_DOC

761 nd Revenue
Accounting -
Accounting

3301 Production a /PRA/RD_CROD, /PRA/RD_RVSL_KLN, /PRA/VL_ACC_DOC, /PRA/VL_ACC_MKT, /PRA/VL_ACC_TAX, /PRA/VL_VDOI_MKT, OIURV_DOC_FRMMKT, OIURV_DOC_FRMTAX, OIURV_DOC_TAXDTL, OIURV_DOC_TAXEMP, OIURV_DOC_TAXMKT
776 nd Revenue
Accounting -
Valuation

3301 Production a /PRA/PP_CHK_ADJ, /PRA/PP_CHKDT_LK, /PRA/PP_DTL_ADJ

782 nd Revenue
Accounting -
Payment Pro
cessing
28. Is there a way to automatize the creation of new range partitions?
Normally it is required to define necessary range partitioning manually. An automatic partitioning is possible using the dynamic range partitioning feature. With the following command you can define a partition as dynamic:

CREATE COLUMN TABLE <table> (<columns>) PARTITION BY RANGE (<part_columns>) (PARTITION OTHERS DYNAMIC THRESHOLD <threshold_rows>)

The partitioning columns need to be dates or numbers.

Dynamic range partitioning for an already range partitioned column can be activated / deactivated in the following way:

ALTER TABLE <table> PARTITION OTHERS DYNAMIC THRESHOLD <threshold_rows>

ALTER TABLE <table> PARTITION OTHERS NO DYNAMIC

When a new dynamic partition is required, SAP HANA renames the existing OTHER partition appropriately and creates a new empty partition. Thus, no data needs to be moved and the process of dynamically adding a partition is very quick.
With this feature you can use the following parameters to automatize the split of the dynamic partition based on the number of records:

Parameter Default Uni Details

t

1000000 rows SAP HANA automatically splits the dynamic partition into two partitions once the row threshold has been reached. The system-wide default can be overwritten by table placement settings (SAP Note 20815
indexserver.ini -> [partitioning] -> dynamic_range_default_threshold
0 91).

900 s This parameter defines how often the threshold check is performed.
indexserver.ini -> [partitioning] -> dynamic_range_check_time_interval_se
c

With current patch levels dynamic range partitioning is per default used in the following scenarios:
BW advanced DSO tables (SAP Note 2081135)
Characteristics with Enhanced Master Data Update
Data Transfer Immediate Storage (DTIS) tables
RSPM* tables (e.g. RSPMDATEPID or RSPMLOG) in BW
Be aware that dynamic range partitioning isn't supported for BW business tables (/.../*) in contexts different from the ones described above.
The dynamic range check can be quite expensive in case many tables with dynamic range partitioning exist because an implicit TABLE_GROUPS lookup can be quite expensive in context of a high number of temporary BW tables. See SAP Note 2000002 -> TABLE_GROUPS (statement hash
25a6171ba41bdf171e818c986177f37e) for more information. The garbage collection (SAP Note 2169283) is globally blocked while the dynamic range check runs.
Be aware that the transactional lock wait timeout for the internal dynamic repartitioning can differ from the default. See SAP Note 1999998 ("Are there specific operations using a non-default transactional lock wait timeout?") for more details.
Starting with SAP HANA 2.0 SPS 06 it is possible to define dynamic range partitioning based on a time or number interval (with <unit> being a time unit like HOUR, MONTH or YEAR):

... PARTITION OTHERS DYNAMIC INTERVAL <count> [<unit>] ...

Example: (one partition for every 3 months)

... PARTITION OTHERS DYNAMIC INTERVAL 3 MONTH ...

Example: (one partition for number intervals of 100000)

... PARTITION OTHERS DYNAMIC INTERVAL 100000 ...

Attention: With SAP HANA <= 2.0 SPS 07 using dynamic intervals with values greater than 2^31 (that can e.g. be useful for date and time columns having values like '20241023132507') can lead to errors or wrong interval calculations (issue number 333564).
In SAP HANA >= CE 2024 QRC2 it is possible to define also a decreasing or bidirectional dynamic range, not only an increasing one:

... DYNAMIC [ INCREASING | DECREASING | BIDIRECTIONAL ] INTERVAL | THRESHOLD...

29. How can I check the progress of an ongoing partitioning activity?

Partitioning activities can be monitored in the following ways:

Tables SQL statement (SAP Note 1969700) Details

M_SERVICE_THREADS SQL: "HANA_Threads_CurrentThreads" Partitioning related thread information can provide insight which tables are currently partitioned and what kind of detailed activity is executed. See SAP Note 2114710 for more information.
M_SERVICE_THREAD_SAMP SQL: "HANA_Threads_ThreadSamples_FilterAndAg
LES gregation"
HOST_SERVICE_THREAD_S SQL: "HANA_Threads_ThreadSamples_Aggregation
AMPLES PerTimeSlice"

M_JOB_PROGRESS SQL: "HANA_Jobs_JobProgress" The view M_JOB_PROGRESS contains information for the current partitioning related activities (JOB_NAME = 'Re-partitioning').

For details how to interpret the details see "How can the job progress details be interpreted for partitioning tasks?" below.

M_EXECUTED_STATEMENTS SQL: "HANA_SQL_ExecutedStatements" The executed statements trace (SAP Note 2366291) provides information about executed DDL operations. You can e.g. run the command with SQL_PATTERN = '%<table_name>%' in order to find all DDL operations th
at were executed in the partitioned table <table_name>.

30. What does _SYS_SPLIT in SAP HANA monitoring views and traces mean?
At different places in monitoring views and trace files (SAP Note 2119087) you can find strings starting with _SYS_SPLIT like:

_SYS_SPLIT_<table_name>~<part_id>

This is the internal representation for a table partition. The trailing identifier indicates the partition ID.

31. What standard partitioning approach is used during migrations?

If a table is partitioned during the migration to SAP HANA (e.g. in order to bypass the 2 billion record limit), HASH partitioning based on the complete primary key is used per default. Per default, tables with more than 1 billion records are considered for partitioning by DMO.
Exception: Tables originating from former physical cluster tables (e.g. BSEG originating from RFBLG) are partitioned by the primary key of that physical cluster table excluding the PAGENO field.
SAP Note 2396601 describes how you can adjust the default partitioning during migrations.
SAP Note 2784715 describe how to configure partitioning in context of SWPM.

32. What should be considered in terms of terminating long running partitioning operations?
Rollbacks of standard and online partitioning activities don't need to undo data modifications, they only need to clean up the target objects like table replicas in case of online partitioning. Thus, the duration of a rollback can be compared with drop or truncate operations and so it is rather
quick, independent of the amount of data already copied.
In case of online partitioning the rollback requires a transactional lock on the source table. If the source table is locked for a longer time by other activities, waiting for the lock can delay the rollback.
Manual termination of partitioning is possible. A rollback happens and no inconsistency is introduced.
With SAP HANA <= 2.00.045 very long running partitioning operations may also be terminated by the MVCC anti ager / kernel sentinel (SAP Note 2169283) with errors like "Data receive failed [Connection reset]" once the idle cursor time exceeds the timeout defined with the following
parameter (default: 12 hours):

indexserver.ini -> [transaction] -> idle_cursor_lifetime

Consider a temporary increase of this parameter if you expect that a partitioning operation takes longer than the configured limit. See SAP Note 2890332 for more information.
With SAP HANA >= 2.00.046 DDL operations like partitioning are no longer considered by the kernel sentinel, so they are not terminated prematurely any more and setting idle_cursor_lifetime is no longer required (issue number 236363).
With SAP HANA >= 2.0 SPS 07 standard table partitioning is terminated after one day (issue number 303599). The timeout can be adjusted with the following parameter (unit: s):

indexserver.ini -> [partitioning] -> request_timeout

Similarly, an online partitioning task may be terminated after a runtime of 7 days due to a table replication read timeout. See SAP Note 3383819 and consider increasing the timeout defined with the following parameter (default: 604800000, unit: ms) in case you expect runtimes of more than
one week:

indexserver.ini -> [table_replication] -> turn_on_request_read_timeout_

33. How can partitioning operations be traced?

You can activate the trace of partitioning operations with the following database trace parameter:

indexserver.ini -> [trace] -> partitioning = debug

See SAP Note 2119087 for more information related to the database trace.
Starting with SAP HANA 2.0 SPS 06 the executed table partitioning commands are written to a trace file with the following naming convention:

<service>_<host>.<port>.table_partition_operation.<cnt>.trc

Its content is available via monitoring view M_TABLE_PARTITION_OPERATIONS respectively SQL: "HANA_Redistribution_PartitionOperations" (SAP Note 1969700). See SAP Note 2119087 -> "Table partition operation trace" for further details.

34. Can range partitions overlap?

No, range partitions need to be disjoint, an overlap isn't possible. Be aware that you have to be careful interpreting boundary information.
Example:

CREATE COLUMN TABLE AAA (X INTEGER) PARTITION BY RANGE (X)

( PARTITION 1 <= VALUES < 100,
PARTITION 100 <= VALUES < 200,
PARTITION OTHERS );

-- alternative notation

CREATE COLUMN TABLE AAA (X INTEGER) PARTITION BY 'RANGE X 1-100,100-200,*'

The partition ranges shown in M_CS_PARTITIONS seem to overlap in value 100:

 -------------------------------------
|TABLE_NAME|PART_ID|RANGE |SUBRANGE|
-------------------------------------
|AAA | 1 |1-100 | |
|AAA | 2 |100-200| |
|AAA | 3 | | |
-------------------------------------

This is a wrong conclusion. The upper limit of the range is exclusive and not inclusive, so value 100 is always inserted in partition 2, never in partition 1.

35. Which errors can happen in relation to partitioning?

The following errors can happen in the partitioning context:

Error message Details

This error is issued if a record is inserted, a value isn't covered by the partition definition and no OTHERS partition is defined.
Could not allocate value '<value>' for column '<column>' to a part of
table <schema>:<table>en. Example:
The table has no rest part. Create a new partition for the value.
The table has no OTHERS part. Create a new partition for the value. A table is defined with range partitions for each calendar year between 2010 and 2016 and now a new record is inserted with calendar year 2017.

Adjust the partitioning or the application logic so that all inserted values are actually covered by the partitioning scheme.

The corresponding Oracle error message is:

ORA-14400: inserted partition key does not map to any partition

Tables with ROUNDROBIN partitioning must not have a primary key because otherwise each INSERT and UPDATE would require a key check in all partitions.
7: feature not supported: cannot use round-robin partitioning with primary key
7: feature not supported: cannot add primary key to round-robin partitioned tabl
e
5001: partition specification not valid; The table has a primary key.
RoundRobin is only allowed for tables without primary keys.

Specifying a NUMA node (e.g. via "ALTER PARTITION ... NUMA NODE") only works for range partitioning. Doing it in other partition contexts, this error is thrown.
7: feature not supported: NUMA node preference not supported
on current partition spec of table: <table>

Online partitioning isn't supported in system databases, it only works on tenant level.
7: feature not supported: online partitioning is not supported in System Databas
e

7: feature not supported: cannot set partition for temporary tables

Partitioning is neither supported for temporary tables (SAP Notes 2800007) nor row tables (SAP Note 2222277).
7: feature not supported: partition is not supported for row tables

7: feature not supported: could not complete partitioning: partition spec must b
In case of sub-partitioning only specific combinations of partition types are allowed.
e Partitioning (ALTER TABLE ... PARTITION) a table with configured data aging (SAP Note 2416490) is also not possible and fails with the same error.
HASH, HASH-HASH, HASH-RANGE, RANGE, or RANGE-RANGE

It is not possible to adjust the load unit of a table using time selection partitioning (SAP Note 3142798).
7: feature not supported: The table is partitioned with a time selection partiti
oning.
For this kind of partitioning it is not allowed to change loading type.

column store error: process parameters error: [2051] partition specification not
First level hash and range partitioning can only be done based on columns belonging to the primary key of the table. If you try to use a different column, you receive this error.
valid;
The column <column> is not a key column.
 7: feature not supported: not allowed on table having page loadable column
This error is issued if an already TIME SELECTION partitioned table is re-partitioned via an ALTER TABLE statement without providing all the TIME SELECTION partitions again (SAP Note 2416490)
Example:
2048: column store error: fail to alter partition: [2593] Error during split/mer A Table TAB_DATAAGING is 1-level HASH 2 partitioned on column B and 2-level TIME SELECTION (RANGE) partitioned with hot partition (00000000) and one cold partition (20100101-20110101).
ge operation;
If a table is partitioned with Time Selection, it is not allowed to repartition If for changing the 1-level HASH partition KEY from B to A following statement is used, the re-partitioning is failing with this error:
to non Time
Selection table except for merging Time Selection range partitions. ALTER table TAB_DATAAGING partition by hash (A) partitions 2;

It is crucial to always provide all sub partitions (RANGES) within the ALTER TABLE statement like:

ALTER TABLE TAB_DATAAGING WITH PARAMETERS('PARTITION_SPEC' = 'HASH 2 A; RANGE[TIME SELECTION: PAGED ATTRIBUTES, NO UNIQUE CHECK] _DATAAGING

00000000,20100101-20110101');

As described in "Which partition types exist?" certain first-level partitionings need to be based on primary key columns. This restriction doesn't exist or can be bypassed for heterogeneous partitioning, see "What is hete
435: invalid expression: partition column not in primary key columns: <columns>
rogeneous partitioning?".

This error happens when you try to create SIMPLE VALID FOR DATA DEPENDENCY data statistics in context of dynamic partition pruning and the table is not partitioned. This statistics type is only useful and permit
1094: invalid combination of settings specified: cannot create
SIMPLE VALID FOR DATA DEPENDENCY on unpartitioned column store table ted in context of partitioned tables.

This message is reported when you try to set up dynamic range partitioning and use a partition limit that is neither a date nor a number or number string.
2048: column store error: fail to alter partition: [2051] partition specificatio
n not valid;
Invalid conversion range: Unable to convert lower bound '<value>' to a number or
date.
Either this lower bound does not represent an integer or date value or it is too
large.

This error is returned when you try to partition a table based on an unsupported column, e.g. using IDENTITY (SAP Note 3459580).
2048: column store error: fail to alter partition: [2051] partition specificatio
n not valid;
The attribute <column> is not allowed in a partition specification.

2048: column store error: fail to alter partition: [2593] Error during split/mer
This error is reported in the following scenarios in scale-out systems:
ge operation; Online partitioning of a table with partitions on different SAP HANA nodes
Moving data between servers is not allowed. During Repartitioning.,object=<objec SAP HANA <= 2.0 SPS 06: Standard partitioning with partitions relevant to a specific split / merge operation being located on different SAP HANA nodes. Partitions that are kept unchanged may reside on differe
t> nt nodes.

As a workaround, you can move all involved partitions to a single node before starting the partitioning.

invalid partition spec: Range value '<value>' for column '<column>' is too large
This error can happen with SAP HANA >= 2.0 SPS 07 due to a new value length check. See SAP Note 2222219 for more information.

36. What are typical partitioning runtimes?

Partitioning performance depends on many factors like available resources and SAP HANA configuration (see "How can the performance of partitioning activities be influenced?" for details). During real-life partitioning of large tables a throughput of 10 to 100 GB / h was observed.

37. Are there specific scenarios where partition pruning isn't possible?
In general SAP HANA tries to take advantage of partition pruning as much as possible. One exception is the use of functions on partition columns. For example, when a table is range partitioned based on month and in the WHERE clause YEAR(<column>) = 2018 is selected, all partitions are
scanned and not only the 12 partitions belonging to the year 2018.

38. What are the main standard partitioning phases?

In SAP HANA 1.0 standard partitioning consists of the following steps:
1. Acquire exclusive lock of table
2. Calculate partition strategy
3. Perform delta merge
4. Create target partitions for the partitions that have changed
5. Distribute the data from the source to the target partitions
6. Finalization tasks, like cleanup of obsolete source partitions and recalculation of internal columns
7. Release exclusive lock of table
In SAP HANA >= 2.0 reduced locking was introduced and standard partitioning consists of the following steps:
1. Acquire shared lock of table
2. Calculate partition strategy
3. Create target partitions for the partitions that have changed
4. Distribute the data of the main part from the source to the target partitions
5. Acquire exclusive lock of table
 6. Distribute the data of the delta part from the source to the target partitions
7. Finalization tasks, like cleanup of obsolete source partitions and recalculation of internal columns
8. Release exclusive lock of table
Online partitioning in SAP HANA 2.0 SPS 05 works as follows:
1. Acquire source table exclusive lock
2. Create replica table
3. Create a snapshot timestamp
4. Enable replica table
a. Demote source table exclusive lock to shared lock
b. Data copy with the snapshot timestamp
c. Replay pending logs appended under shared lock
5. Delta merge and optimize compression for replica (SAP Note 2057046, motivation: HARD)
6. Promote source shared lock to exclusive lock
7. Replay pending logs appended while exclusive lock promotion
8. Swap source and replica
9. Release source table exclusive lock and the snapshot timestamp
Online partitioning in SAP HANA >= 2.0 SPS 07 works as follows:
1. Acquire source table exclusive lock
2. Create replica table
3. Enable replica (source partition by source partition):
a. Acquire source table exclusive lock (skip for the first partition because it is already acquired)
b. Create a snapshot timestamp (in case of partitioned table: for the partition)
c. Demote source table exclusive lock to shared lock
d. Data copy with the snapshot timestamp
e. Replay pending logs appended under shared lock
f. Release the snapshot timestamp
4. Delta merge and optimize compression for replica (SAP Note 2057046, motivation: HARD)
5. Promote source shared lock to exclusive lock
6. Replay pending logs appended while exclusive lock promotion
7. Swap source and replica
8. Release source table exclusive lock
During online partitioning, table optimizations triggered by the mergedog can happen at any time (SAP Note 2057046).

39. How can the performance of partitioning activities be influenced?

The following factors influence runtime and performance of partitioning activities:

Area SAP Details

Note
s

System resour 1999 Available system resources in terms of CPU and memory can impact the partitioning runtime. It is important that enough memory is available to partition without having to perform unloads or swapping.
ces 997
2100
040

Disk I/O perfo 1999 Bottlenecks in the I/O stack can significantly increase the partitioning time.
rmance 930

System replica 1999 Partitioning is responsible for a significant amount of generated redo logs that need to be synchronized with secondary system replication sites. Make sure that no bottlenecks exist in that area or consider deactivating system replication when time critical partitioning is executed.
tion 880

SAP HANA co 2222 In general it is important to make sure that SAP HANA is configured based on SAP best practices as described in SAP Note 2600030 or special targeted workload settings are implemented for the duration of partitioning (SAP Note 2222250). In addition you can use the following setting to
nfiguration 250 adjust parallelism for split and bulk load during standard table partitioning (SAP Note 2222250):
2600
030 indexserver.ini -> [partitioning] -> split_threads
2874 indexserver.ini -> [partitioning] -> bulk_load_threads

176
3469 Be aware that these parameters only apply to standard partitioning, not to online partitioning.
162 Higher values result in higher parallelism if sufficient resources are available and the partitioning criteria fulfill the multiple / divider rule (see "Partitioning criteria" below). If SAP HANA downgrades the parallelism due to limited memory, the following entry is written to the database trace
(SAP Note 2380176):

Requested to split index with X threads. As the memory is scarce, the number of threads is reduced to Y.

SAP Note 2874176 provides further parameter recommendations for online partitioning activities.

SAP Note 3469162 provides information for online partitioning on SAP HANA 2.0 SPS 07.
 Delta storage 2057 Size and workload on the delta storage can have a performance impact, so the following considerations are useful:
046
Make sure that the initial delta storage is small and consider an explicit delta merge in case of larger delta storages.
Minimize the amount of change operations that happen in parallel to the ongoing partitioning so that the delta storage size is kept small.

SAP Note 2871405 suggests a change to the auto merge decision function in context of online repartitioning operations in order to increase the number of merges, thus reducing the memory requirements.

Partitioning cr If you partition tables that are already partitioned, the following rules can reduce the effort and runtime:
iteria
Online repartitioning:

Online repartitioning is performed sequentially, partition by partition. While reading from the source partition can take advantage of concurrency settings, the parallelism of other operations like PartitionUpdateJobNode or ColumnsToDataBufferJob is bound to the number of target
partitions related to a certain source partition. Thus, it is optimal for the repartitioning performance when the records in a source partition are rather evenly distributed across a lot of target partitions. This can e.g. be achieved in context of HASH partitioning when the number of sourc
e of target partitions have no common divisor. For example, a repartitioning from HASH 10 to HASH 21 will be better parallelized than a repartitioning from HASH 10 to 20.

Attention: Be aware that higher parallelism can introduce other bottlenecks (I/O, table optimization, snapshot synchronization) and an "unusual" partition count can be negative for other aspects like a good distribution of partitions across SAP HANA nodes. Thus, adjusting the parti
tion count just for online repartition performance should only be done in specific, well understood scenarios.

Standard repartitioning:
HASH, ROUNDROBIN: Choose a new number of partitions that is a multiple or divider of the current number of partitions, because in this case SAP HANA is able to parallelize on source partitioning level. This rule also applies for multi-level partitioning. Both levels can be treated in
dividually (e.g. repartitioning from 2/2 partitions to 2/4, 8/2 or 16/16 partitions possible).
RANGE with OTHERS partition: When adding a new range to this table only new partitions for the new range and a new OTHERS partition are created. The data distribution time highly depends on the size of the OTHERS partition since all the data of the old OTHERS partition has t
o be redistributed either in the newly created range partition or the new OTHERS partition.
previously non-partitioned tables: For tables that are currently not partitioned at maximum one thread per column can be used to distribute the data to the new partitions.
Number of target partitions: An increased number of target partitions can have a positive impact on performance because higher concurrency and less contention is possible. Be aware that a higher number of partitions can have disadvantages during normal operation, e.g. increased c
olumn value materialization times ("Materialize results" or "ProjectBufferOp" in PlanViz), so both advantages and disadvantages should be carefully considered when deciding for a number of target partitions.

Availability of 2127 All table data has to be read during partitioning, so in the following scenarios significant overhead can be introduced when data has to be read from disk:
table data in 458
Columns that weren't loaded to memory before
memory 2220
Access to disk LOBs that are not cached in the SAP HANA page allocator
627
The following command can be used to load all column tables into memory:

LOAD "<table_name>" ALL

From a LOB perspective it is more efficient to use packed LOBs. If a table doesn't contain packed LOBs, yet, the following can be used for migrating (SAP Note 2220627):

ALTER TABLE "<schema_name>"."<table_name>" LOB REORGANIZE [ONLINE]

Attention: With SAP HANA <= 2.00.046 orphan persistence files can remain in case packed LOBs were already used before and a manual cleanup is required (SAP Note 2910004).

Index conside 2160 The existence of large multi-column indexes can slow down the partitioning throughput in some cases. You can detect expensive index processing via thread analysis (SAP Note 2114710). For example, the following thread method indicates expensive parallelized processing for the primary k
rations 391 ey ($trexexternalkey$):

split/merge attribute <schema>:<table> $trexexternalkey$

Consider the following optimizations:

In case of large primary keys you can consider a transition to index type inverted individual (SAP Note 2600076). This will reduce memory consumption and partitioning overhead, but depending on the inverted individual costs the CPU consumption and runtime of table accesses can
increase to a certain extent.
Review if it is really necessary to keep large multi-column secondary indexes in place. In many cases multi-column secondary indexes aren't required and can be dropped or replaced with more efficient single-column indexes.
In case you can't take advantage of inverted individual primary indexes or removal of secondary indexes, it is in some cases possible that a recreation of the index after the partitioning is quicker than the actual partitioning of the index. In this case you can proceed as follows and drop t
he index before starting the partitioning:

Make sure that the application is stopped (in case of primary keys and unique indexes to avoid risk of duplicate keys)
Drop the index / constraint (DROP INDEX / ALTER TABLE ... DROP CONSTRAINT)
Perform the actual partitioning
Recreate the index / constraint (CREATE INDEX / ALTER TABLE ... ADD CONSTRAINT)

Large column With standard partitioning the overall runtime can be dominated by a large column. If you can't eliminate the dominating column (e.g. by "Index considerations" in case the column is the concat attribute of an index), you can consider using online partitioning instead of standard partitioni
s ng because large columns don't have the same impact for online partitioning.

40. How does an example for partitioning look like?

To explain the details of partitioning we use the following table as an example which is distributed over two indexserver running on port <indexserver_port> on hosts <HOST_A> and <HOST_B>:
 CREATE COLUMN TABLE <SCHEMA_NAME>.<TABLE_NAME> (a INT, b INT, c INT, PRIMARY KEY (a,b))
PARTITION BY
HASH (a, b) PARTITIONS 2,
RANGE (c)
(PARTITION 1 <= VALUES < 5,
PARTITION OTHERS)

The partition specification is changed in such a way that on first level now 4 instead of 2 partitions exist. On second level an additional range partition for the range 5 <= c < 10 is added:

ALTER TABLE <SCHEMA_NAME>.<TABLE_NAME>

PARTITION BY
HASH (a, b) PARTITIONS 4,
RANGE (c)
(PARTITION 1 <= VALUES < 5,
PARTITION 5 <= VALUES < 10,
PARTITION OTHERS);

The number of hash par­­titions is increasing from 2 to 4. 4 is a multiple of 2. As described in "How can the performance of partitioning activities be influenced?", this means that the partition task can parallelize per source hash partition.
On the second partition level only one new range is added while the definition of the previously existing range is not changed. For this reason, further parallelization based on every source range partition can be performed.
Here you can find a visualization of the initial partitioning scheme, its changes and the data flow during the reorganization:

41. How can the job progress details be interpreted for partitioning tasks?
The monitoring view M_JOB_PROGRESS contains detailed information about partitioning progress that depends on the SAP HANA version.
Important details for SAP HANA 1.0 are:
CURRENT_PROGRESS: Number of partitioned columns
MAX_PROGRESS: Total number of columns that need to be partitioned (including internal columns)
With SAP HANA >= 2.0 the M_JOB_PROGRESS monitoring view contains more detailed information. It first contains information about the overall status of the MASTER process. This master process can create worker groups which are called GRP1, GRP2, … Basically every possible
parallelization per partition gets assigned one group. Each group then can have up to one worker thread per partition column. These worker threads are called WORK0, WORK1, …
Important details for SAP HANA >= 2.0 are:
CURRENT_PROGRESS: This value shows how many steps are already processed. Details about the current step can be found in the PROGRESS_DETAIL column.
MAX_PROGRESS: Shows the overall number of steps that need to be performed. Depending on the process type a different number of total steps exists:

The master process has in total 7 steps: Mapping, GetDataRanges, PreProcess, RepartitionMain, RepartitionDeltaAndMVCC, PostProcess, DropSources
Each worker group consists of 13 steps: CreateTargets, DeterminepartsMain, DeterminepartsDelta, InitPersistenceMain, InitPersistenceDelta, CheckConsistencyMain, CheckConsistencyDelta, RepartitionMainLocal, RepartitionDeltaLocal, RepartitionMVCCMain,
RepartitionMVCCDelta, UpdateRuntime, Finalize
Each thread worker has 3 steps: SplitMergeAttributes, Save, Idle
PROGRESS_DETAIL: [MASTER|GRPX|WORKX] [COLUMN_NAME] STEP_NAME
Shows more details about the individual process:
 For the master process it shows “MASTER” and the step of the overall repartition task.
Example: MASTER RepartitionMain
For a worker group it shows the name of the group and the current step of the group. Additionally, it shows in brackets the partition IDs of the source table on which this group is working on.
Example: GRP1 RepartitionMainLocal (1)
For a worker thread it shows the name of the worker and the current step of the worker thread. Moreover, it shows the name of the column for which it is currently repartitioning the data. Furthermore, the number of columns for which the redistribution finished when the step
started and the overall number of columns in this partition is shown in brackets.
Example: WORK1 A (3/6) SplitMergeAttribute
Attention: The number of all columns also includes all internal columns. For some of these columns, like $rowid$ or $trex_udiv$, a special handling at the end of the repartition run exists. For this reason, it is likely that you will not see worker threads for the complete number of
(internal) columns.

42. What are tables with names starting with "_SYS_OMR_"?

Tables with the naming convention _SYS_OMR_<source_table>#<id> are used as interim tables during online partitioning operations that are triggered by commands like:

ALTER TABLE "<source_table>" PARTITION BY ... ONLINE

Actually the online partitioning is based on table replication (SAP Note 2340450) and "OMR" in this context is the abbreviation for "online-mode replica".

43. What kind of resources are required during partitioning?

When doing partitioning you have to consider that significant requirements for specific system resources can exist:

Resource Details

CPU Several SAP HANA threads can work on the same partitioning operation in parallel, so a significant amount of CPU resources can be consumed. See How can the performance of partitioning activities be influenced? -> "SAP HANA Configuration" for more information.

Memory During partitioning both the old and the new table is held in memory and the new table is initially set up without compression, so the memory requirements for the table can be factors higher until both partitioning and delta merge and optimize compression is finished.

Online partitioning always recreates the complete table including all partitions. Standard partitioning only recreates the partitions that are modified by the actual partition operation.

SAP Note 3568889 describes an alternative way of repartitioning based on export / import. It is an offline approach that can be used to repartition a table with minimal memory overhead.

Disk The increased (intermediate) table data is also persisted to disk, so also the used space in the data area increases. Once all operations are finished, the additional disk space is released but kept allocated. It can be reclaimed via RECLAIM DATAVOLUME (SAP Note 2400005).

Log All data that is inserted in the new table is written to the redo logs, so a significant amount of redo logs can be generated during partitioning. This may have impact on the overall system performance in case of bottlenecks in the I/O area (SAP Note 1999930) or system replication (SAP Note 1999880).

With SAP HANA >= 2.00.059.13 and >= 2.00.077 the redo log generation for standard partitioning is reduced by about 40 % because an unnecessary serial data write operation is removed (issue number 319111).

Be aware that in context of partitioning explicit and implicit table optimizations are performed (SAP Note 2057046) which similarly to partitioning itself can consume a lot of system resources.

44. What is heterogeneous partitioning?

The normal second-level range partitioning schema applies the same second level specification to all first level partitions. For some scenarios a flexible heterogeneous second-level range partitioning schema can be useful with different second-level range specifications for each first level
partition. Heterogeneous partitioning is available starting with SAP HANA 2.0 SPS 03. See the Heterogeneous Partitioning section of the SAP HANA online help for more details.
Example: (Heterogeneous 2-level range-range partitions)

The deciding factor in the heterogeneous partitioning syntax are the brackets highlighted yellow. Alternatively you can identify heterogeneously partitioned tables by the term "CompactPartitionSpec2" being part of the partition specification (e.g. visible in column PARTITION_SPEC of view
TABLES).
For usual partitioning the first level partitioning columns need to be part of the primary key (see "Which partition types exist?"). This restriction doesn't apply for heterogeneous partitioning. So in specific cases heterogeneous partitioning syntax can be used just for the purpose of avoiding the
primary key column limitation.
Example:

CREATE TABLE AAA (A INT PRIMARY KEY, B INT) PARTITION BY RANGE (B) (PARTITION OTHERS)
-- 435: invalid expression: partition column not in primary key columns: B

CREATE TABLE AAA (A INT PRIMARY KEY, B INT) PARTITION BY RANGE (B) ((PARTITION OTHERS))
-- works fine
Strictly speaking, this partitioning is homogeneous, but due to the heterogeneous partitioning syntax, it is also called heterogeneous and restrictions for homogeneous partitioning don't apply.
Attention: Be aware that in SAP HANA Cloud a primary key check is per default also done in context of heterogeneous partitioning. You can suppress it via the NO PRIMARY KEY CHECK option (SAP Note 3509522). Vice versa, the primary key check can be explicitly activated in SAP HANA
2.0 >= SPS 06 using the PRIMARY KEY CHECK option.

45. Which types of partition pruning exist?

Partition pruning makes sure that only partitions are accessed that are relevant for the query. Technically, two different pruning engines exist:
Legacy Pruning Engine
API: TRexAPI::Partitioning::PruningRuntime::processDynamicDataStatistics
Used by OLAP, OLTP, table update, join engine, search, ...
New Pruning Engine
API: partitioning::sqloptimizer::PartitionAwareOptimizationInterface::dynamicPartitionPruning
Used by HEX engine (SAP Note 2570371) only
The following pruning types are distinguished:

Pruning t Details
ype

Static parti Static partition pruning is based on the partition definition. The query optimizer analyzes the WHERE clause of queries to determine whether or not the filters match the given partitioning specification of a table. If a match is found, it may be possible to target only the specific partitions that hold the d
tion pruni ata and thus reduce the number of partitions being queried.
ng

Dynamic p Dynamic partition pruning is content-based and can be applied to historical partitions in context of data aging (SAP Note 2416490) or Native Storage Extension (SAP Note 2799997). This type of pruning takes place at run time but the decision about which partitions to load is based on pre-calculated c
artition pr olumn statistics of the data in selected columns. Based on the existence of statistics valid for partition pruning (which must be up to date at the time the query is processed), query evaluation can determine if it is necessary to read the partitioned column of data and load it into memory. Dynamic partiti
uning on pruning can also be of advantage in context of partitioned column store tables (independent of NSE or data aging), e.g. in order to reduce accesses to remote partitions in scale-out scenarios.
For homogeneously partitioned tables dynamic pruning is available for all engines. For the OLAP engine it has to be activated explicitly with the following parameter setting:

indexserver.ini -> [query_mediator] -> use_dynamic_pruning = true

Heterogeneous partitioning is only supported by HEX (SAP Note 2570371).

Only the following datatypes are supported for dynamic partition pruning:

VARCHAR (strings with numeric content)

INTEGER
DECIMAL
DATE

In addition data statistics (SAP Note 2800028) of type SIMPLE VALID FOR DATA DEPENDENCY need to be defined on relevant columns:

CREATE STATISTICS ON "<table>" ("<column>") TYPE SIMPLE VALID FOR DATA DEPENDENCY

You can use SQL: "HANA_SQL_Statistics_DataStatistics" (SAP Note 1969700) in order to check for existing statistics.

The statistics become invalid as soon as a data modification happens. They will be recreated during a delta merge (SAP Note 2057046) of the table or manually with the following command:

REFRESH STATISTICS ON "<table>"

See Static and Dynamic Partition Pruning for more information.

46. How can database requests be restricted to a subset of partitions of a table?

It is possible to limit database requests to only specific partition IDs by specifying one or more partition IDs via the following PARTITION clause:

PARTITION(<part_id1>, ..., <part_idN>)

The partition IDs can e.g. be determined via output column PART of SQL: "HANA_Tables_ColumnStore_Partitions" available via SAP Note 1969700 or via column PART_ID of various SAP HANA monitoring views.
Example: (selection of records from MY_PART_TABLE partitions 2, 5 and 8)

SELECT * FROM MY_PART_TABLE PARTITION (2, 5, 8)

47. What has to be considered for secondary system replication sites when doing partitioning?
Partitioning adjustments are automatically inherited to secondary system replication sites (SAP Note 1999880), so no further activitiy is required on secondary sites. See SAP Note 2952826 for more information.

48. How can some small, but not completely empty partitions be merged efficiently?
Having several small, hardly filled partitions can result in some unnecessary overhead. Thus, it is recommended to keep their number at a minimum. While empty partitions could be dropped, it is not possible to merge some partitions with little data explicitly with a MERGE command. In
order to combine them, you can perform a standard partitioning to the new intended target layout. Standard partitioning generally tries to keep the amount of moved data at the lowest level, so if 99 % of data is in large partitions, they are kept unchanged while only the data in the smaller
partitions is combined according to the intended target structure.
Be aware that this efficient approach is only possible with standard partitioning. Online partitioning will generally rebuild the whole table, including all large partitions that are supposed to remain unchanged.
See SAP Note 3313721 for more information about adjusting the partition layout without having to rebuild the complete table from scratch.
49. What are differences between standard and online partitioning?
Although syntactically quite similar, the procedure of standard and online partitioning is different in various respects:

Aspect Standard partitioning Online partitioning

transactional table lock for short synchronizations and during delta storage processing for short synchronizations

execution of concurrent modifications possible possible

technical implementation partitioning table replication

temporary objects none _SYS_OMR_<source_table>#<id>

data copy column based row based

amount of data recreated only what is required (e.g. partitions with unchanged definition are kept) always all

parameter settings split_threads, bulk_load_threads SAP Notes 2874176, 3469162

parallelism controlled by parameters depends on target partition layout

rollback usually quick can take longer when transactional lock on source table isn't available for a longer time

partitions on different scale-out nodes supported can result in errors like "Search result size limit exceeded" when a table has more than 2 billion records (issue number 301776)

50. Is the online option available for all partition operations?

Online partitioning always involves a recreation of the complete table. This can be a significant overhead for minor actions like adding a new partition. Thus, partitioning activities like adding a partition don't support the ONLINE option. If you want to perform a minor change with the
ONLINE option, you have to specify the complete partition layout.
Example:

CREATE COLUMN TABLE T1 (A INT, B INT);

ALTER TABLE T1 PARTITION BY RANGE (A) ( PARTITION 10 <= VALUES < 20, PARTITION 20 <= VALUES < 30, PARTITION OTHERS);

ALTER TABLE T1 ADD PARTITION VALUES = '31';

-- offline, works fine

ALTER TABLE T1 ADD PARTITION VALUES = '32' ONLINE;

-- online, failure
-- [257]: sql syntax error: incorrect syntax near "ONLINE"

ALTER TABLE T1 PARTITION BY RANGE (A) ( PARTITION 10 <= VALUES < 20, PARTITION 20 <= VALUES < 30, PARTITION VALUES = 32, PARTITION OTHERS) ONLINE;
-- online with full partition specification, works fine

51. How can I check to which hash partition a specific value would map?
In SAP HANA Cloud >= 2024.QRC3 you can use the hash function PARTITION_HASH to identify the partition to which a record with specific values <value1>, ..., <valueN> in the hash columns would map:

SELECT MOD(PARTITION_HASH(<value1>) + ... + PARTITION_HASH(<valueN>), <partition_count>) + 1 FROM DUMMY

Example: (check for partition of hash column values 'SMITH' and 12345 in case of 8 partitions)

SELECT MOD(PARTITION_HASH('SMITH') + PARTITION_HASH(12345), 8) + 1 FROM DUMMY

In SAP HANA on-premise this functionality is not available.

52. Can I split a partition by only moving a smaller amount of data to a new partition?
In some urgent scenarios, e.g. when the 2 billion record limit is reached in one of the partitions, it is important to adjust the partitioning design with least efforts and runtime.
Example: (Overflow partitions reached 2 billion record limit in September 2024)
 TABLE_NAME MEM_SIZE_GB RECORDS LEVEL_1_PARTITIONING
============= =========== ============ ====================================
DBTABLOG (1) 0.00 0 RANGE ("LOGDATE") 20000101-20180101
DBTABLOG (2) 3.08 67963367 RANGE ("LOGDATE") 20180102-20190101
DBTABLOG (3) 1.60 34951364 RANGE ("LOGDATE") 20190102-20190201
DBTABLOG (4) 1.12 22383031 RANGE ("LOGDATE") 20190202-20190301
DBTABLOG (5) 1.19 23855207 RANGE ("LOGDATE") 20190302-20190401
DBTABLOG (6) 1.13 22121918 RANGE ("LOGDATE") 20190402-20190501
DBTABLOG (7) 1.19 23627384 RANGE ("LOGDATE") 20190502-20190601
DBTABLOG (8) 1.46 30504073 RANGE ("LOGDATE") 20190602-20190701
DBTABLOG (9) 1.41 29851229 RANGE ("LOGDATE") 20190702-20190801
DBTABLOG (10) 0.58 12232883 RANGE ("LOGDATE") 20190802-20190901
DBTABLOG (11) 0.56 12376271 RANGE ("LOGDATE") 20190902-20191001
DBTABLOG (12) 0.64 14284393 RANGE ("LOGDATE") 20191002-20191101
DBTABLOG (13) 0.72 16291251 RANGE ("LOGDATE") 20191102-20191201
DBTABLOG (14) 1.09 24733104 RANGE ("LOGDATE") 20191202-20200101
DBTABLOG (15) 17.64 355737578 RANGE ("LOGDATE") 20200102-20210101
DBTABLOG (16) 105.27 2147224535 RANGE ("LOGDATE")

In this scenario it would be perfect if the overflow partition can be split via ADD PARTITION in a larger (e.g. 20210101 to 20240630) and a smaller time interval (only values after June 2024) and only the records of the smaller time interval are moved to the new partition while most of the
records remain in the existing partition and don't have to be moved. Unfortunately, this is not possible because it would involve DML operations (i.e. moving records from partition to partition via INSERT and DELETE), thus resulting in additional consistency requirements and overhead
during terminations and rollbacks. In any case all data from adjusted partitions has to be moved. For online repartitioning, also data from non-adjusted partitions has to be moved on top.
In order to get some relief from the 2 billion record limit, you can check if clearing / deleting / archiving records is possible. On SAP HANA >= 2.0 SPS 07 you can also temporarily increase the record limit from its default of 2.10 billion to 2.14 billion (SAP Note 2154870):

indexserver.ini -> [unifiedtable] -> max_records_in_column_table_partition_for_dml = 2147483645

You may also create a new partition that starts right after the maximum value of the existing huge partition. When no records have to be moved at all, the new and empty partition will be created without any record move overhead. For example, if the maximum LOGDATE value in DBTABLOG
in the above example is 20240916, you can add a partition starting 20240917 so that from the next day on all new records go into the new, empty partition:

ALTER TABLE DBTABLOG ADD PARTITION '20240917' <= VALUES < '20250101'

53. Is it necessary to keep the application informed about repartitioning on SAP HANA level?
ABAP, as one prominent application utilizing SAP HANA, has no own partitioning information. Instead it reads the partition state of the database level. See Is the partitioning information kept during transports? and Is the partitioning information kept during ABAP table conversions and SAP
upgrades? for more information. Thus, there is no requirement to maintain partitioning details on ABAP level.
If the application has an own "design-time" view on the table setup, it is important to reflect repartitioning also on application side. For example, in HANA Deployment Infrastructure (HDI) / XS Advanced (XSA) environments (SAP Note 2596466) it is important to define the partitioning
details in the "technical configuration" section of the entity as described in CDS Entity Syntax Options in XS Advanced:

technical configuration {
<partition_clause>;
}

Otherwise, the next table conversion after partitioning will automatically revert the table into a non-partitioned state and unexpected error like the following are possible (issue number 334583):

[2593] Error during split/merge operation;The count of target partitions (1) is not enough to store all <table_records>
rows of the source partitions, will exceed physical limitation of 2147483645 rows per partition

See Table Partitioning in HDI Environments for more information.

54. Is it possible to define explicit names for partitions?

Starting with CE 2024 QRC4 it is possible to define and unset explicit names for range partitions using SET NAME and UNSET NAME.

ALTER TABLE "<table>" ALTER PARTITION <part_id> SET NAME "<partition_name>"

ALTER TABLE "<table>" ALTER PARTITION <part_id> UNSET NAME

The defined names can also be used when explicitly selecting from a subset of partitions as described in How can database requests be restricted to a subset of partitions of a table?.
The defined names can be found in column PART_NAME of monitoring view M_TABLE_PARTITIONS.

Keywords
Record count,Table growth,Billion,HASH,ROUNDROBIN,RANGE,CHECK_PARTITIONING,CHECK_PARTITIONING_DATA,too many records

Attributes
Key Value
Other Components SAP HANA > SAP HANA Database (HAN-DB)

Products
Products

SAP HANA, platform edition all versions

This document refers to

SAP Note/KBA Component Title

3568889 HAN-DB

3509522 HAN-CLS-HC "invalid expression: partition column not in primary key columns" is raised when you create a table

3459580 HAN-DB-ENG Partitioning a table column with IDENTITY feature report error [2051] partition specification not valid

3383819 HAN-DB-ENG Error in online repartition

3313721 HAN-DB How to split/break a specific RANGE partition in already partitioned table which contains data in SAP HANA?

3142798 HAN-DB-NSE Re-partitioning of time selection (RANGE) table is required to change partitioning definition

2952826 HAN-DB-HA Perform table partitioning on HANA primary site requires additional steps on secondary site?

2890332 HAN-DB Table re-partitioning failed with error "Data receive failed"

2845463 CO-PC-ACT CKMLCR Table reached 2B limit in HANA

2800028 HAN-DB FAQ: SAP HANA Optimizer Statistics

2800007 HAN-DB FAQ: SAP HANA Temporary Tables

2799997 HAN-DB-NSE FAQ: SAP HANA Native Storage Extension (NSE)

2600076 HAN-DB FAQ: SAP HANA Inverted Individual Indexes

2600030 HAN-DB Parameter Recommendations in SAP HANA Environments

2570371 HAN-DB-ENG FAQ: SAP HANA Execution Engine (HEX)

2528241 HAN-DB Partitioning of tables replicated by SLT to SAP HANA database

2470289 HAN-DB FAQ: SAP HANA Non-Uniform Memory Access (NUMA)

2416490 HAN-DB FAQ: SAP HANA Data Aging in SAP S/4HANA

2400005 HAN-DB-PER FAQ: SAP HANA Persistence

2396601 HAN-DB How to change the partitioning information for a table during the DB migration to HANA

2388483 HAN-DB How-To: Data Management for Technical Tables

2380176 HAN-DB FAQ: SAP HANA Database Trace

2375917 HAN-DB How-To: Converting SAP HANA VARBINARY columns to LOB

2366291 HAN-DB FAQ: SAP HANA Executed Statements Trace

2340450 HAN-DB FAQ: SAP HANA Table Replication

2313619 HAN-DB-MON How-To: Generating and Evaluating SAP HANA Call Stacks

2222277 HAN-DB-PER FAQ: SAP HANA Column Store and Row Store

2222250 HAN-DB-PERF FAQ: SAP HANA Workload Management

2222219 HAN-DB SAP HANA Errors and different Results due to Design Changes

2222217 HAN-DB How-To: Troubleshooting SAP HANA Startup Times

2222200 HAN-DB FAQ: SAP HANA Network

2222110 HAN-DB-PERF FAQ: SAP HANA Load History

2220627 HAN-DB FAQ: SAP HANA LOBs

2169283 HAN-DB-ENG FAQ: SAP HANA Garbage Collection

2160391 HAN-DB-ENG FAQ: SAP HANA Indexes

2154870 HAN-DB How-To: Understanding and defining SAP HANA Limitations

2143736 HAN-DB-ENG-BW FAQ: SAP HANA Table Distribution for BW

2127458 HAN-DB FAQ: SAP HANA Loads and Unloads

2119087 HAN-DB How-To: Configuring SAP HANA Traces

2116157 HAN-DB FAQ: SAP HANA Consistency Checks and Corruptions

2114710 HAN-DB-MON FAQ: SAP HANA Threads and Thread Samples

2112604 HAN-DB-ENG FAQ: SAP HANA Compression

2109355 HAN-DB How-To: Configuring SAP HANA Inverted Hash Indexes

2100040 HAN-DB-PERF FAQ: SAP HANA CPU

2100009 HAN-DB-ENG FAQ: SAP HANA Savepoints

2081591 HAN-DB-PER FAQ: SAP HANA Table Distribution

2057046 HAN-DB-ENG FAQ: SAP HANA Delta Merges

2014562 CA-LT-SLT FAQ: SAP HANA LT Replication Server (SLT)

2000002 HAN-DB-PERF FAQ: SAP HANA SQL Optimization

1999998 HAN-DB-PERF FAQ: SAP HANA Lock Analysis

1999997 HAN-DB FAQ: SAP HANA Memory

1999993 HAN-DB-MON How-To: Interpreting SAP HANA Mini Check Results

1999930 HAN-DB FAQ: SAP HANA I/O Analysis

1999880 HAN-DB-HA FAQ: SAP HANA System Replication

1998599 HAN-DB How-To: Analyzing high SAP HANA Memory Consumption due to Translation Tables

1986747 HAN-DB-PER How-To: Analyzing internal Columns in SAP HANA Column Store

1910188 HAN-DB-MON How to handle HANA Alert 27: ‘Record count of column-store table partitions’

1910140 HAN-DB-MON How to Handle Alert 20 ‘Table growth of non-partitioned column-store tables’

1909763 HAN-DB-MON How to handle HANA Alert 17: ‘Record count of non-partitioned column-store tables’

3469162 HAN-DB Online Partitioning SAP HANA 2 SPS07

3325787 XX-SER-REL-S4HANA Partition-Distribution of Financial Data in SAP S/4HANA

3301782 IS-OIL-PRA Best Practices for Partitioning of PRA Payment Processing Tables

3301776 IS-OIL-PRA Best Practices for Partitioning of PRA Valuation Tables

3301761 IS-OIL-PRA Best Practices for Partitioning of PRA Accounting Tables

3139140 CO-PC-ACT Partitioning for material ledger tables MLDOC and MLDOCCCS

3051343 CA-RT-XRP Table Partitioning for SAP Replenishment Planning (for Single-Host Scenarios)

2910004 HAN-DB Increase Disk Usage After Performing DDL Operation on Table With Packed LOB Column

2874176 HAN-DB Parameter Recommendations for Online Table Operations

2873607 HAN-DB Potential Performance Impact by Concurrent Online DDLs

2871405 HAN-DB Elevated Memory Consumption During Online Table Repartitioning

2849678 FS-AM Performance SAP Transactional Banking for SAP S/4HANA - partitioning

2784715 HAN-LM-INS-SAP SWPM: Using R3load-based migration for SAP System on HANA when tables contain more than 2 billion rows

2722355 FS-FPS Partitioning of database tables in S4FPSL

2700982 CA-DDF-RT-UDF Table Partitioning for Unified Demand Forecast and Demand Data Foundation (for Multiple-Host Scenarios)

2596466 BC-XS-RT FAQ: SAP HANA XS advanced

2546640 FI-RA Partitioning of fast growing tables in SAP Revenue Accounting and Reporting

2524869 FS-BA Partitioning of database tables for Smart AFI

2436619 HAN-DB Inconsistency After Repartitioning a Table Using Inverted Hash Indexes

2334091 HAN-DB-ENG-BW SAP BW/4HANA: Table Placement and Landscape Redistribution

2289491 FI-GL Best Practices for Partitioning of Finance Tables

2259038 MM-IM-GF-MIG S/4HANA: Partitioning of table MATDOC

1969700 HAN-DB SQL Statement Collection for SAP HANA

1908075 HAN-DB-ENG-BW SAP BW on SAP HANA: Table Placement and Landscape Redistribution

1548125 BW-BEX-OT-NC Interesting Facts about Non-Cumulatives

Characteristics with Enhanced Master Data Update

 Static and Dynamic Partition Pruning

Partitioning Limits

Heterogeneous Partitioning

SAP BW/4HANA - Creating DSO Partitions

Data Transfer Immediate Storage (DTIS)

SAP BW on HANA - Creating DSO Partitions

Static and Dynamic Partition Pruning

SAP HANA Administration Guide

CDS Entity Syntax Options in XS Advanced

Table Partitioning in HDI Environments

This document is referenced by

SAP Note/KBA Component Title

3583617 ARCHIVED Table partitioing failed with "invalid range" error

3577228 HAN-DB How to Resolve “Maximum Number of Rows per Partition Reached” on Table ACDOCA Using Hash Partitioning

2938647 HAN-DB How many levels partition are supported by HANA

3519455 HAN-DB-ENG When exporting or importing HANA table, the table will retain the partitioned status?

2000003 HAN-DB-ENG FAQ: SAP HANA

3520079 HAN-DB-ENG-BW Error While Determining the Package Dimension Entries in DTP

3482330 HAN-DB-ENG Understanding the PARTNAMES Parameter in SAP HANA Table Partition Specification

2124112 HAN-DB-PERF FAQ: SAP HANA Parsing

1805810 HAN-DB-ENG Partitioning a SAP HANA database table causes error: [2051] partition specification not valid

3167108 HAN-DB-ENG-BW After running table distribution, the table is not partitioned - SAP BW on SAP HANA

3417429 HAN-DB-ENG SAP HANA Dynamic Range Partitioning

2470289 HAN-DB FAQ: SAP HANA Non-Uniform Memory Access (NUMA)

3380524 HAN-DB-PER High persistent memory utilization during online partitioning

3361087 HAN-DB-ENG Partition specification not valid;Invalid integer-like range: Length of bound '00000000000' is not equal to the length 10 of the partitioning column

3234063 HAN-DB How to partition/re-partition a table.

3356042 HAN-DB Will partitioning help to reduce the disk/memory footprint of the table in SAP HANA?

3327494 HAN-DB How to distribute the rows evenly across the partitions

3313721 HAN-DB How to split/break a specific RANGE partition in already partitioned table which contains data in SAP HANA?

2000000 HAN-DB-PERF FAQ: SAP HANA Performance Optimization

3288401 HAN-DB How to find information about actual table partitioning in SAP HANA?

3284656 HAN-DB-ENG Client Copy on SAP HANA fails with "maximum number of rows per table or partition reached" error

3281773 HAN-DB What cause the non uniform data distribution in HASH partitioned table in SAP HANA?

2999990 HAN-DB-PERF How-To: SAP HANA Performance Analysis

3215774 HAN-DB-ENG Monitor and troubleshoot for a long process of table repartition

3146645 HAN-DB-ENG What is the best approach in partitioning tables on SAP HANA?

3096029 HAN-DB-ENG The main standard partitioning phases

2112604 HAN-DB-ENG FAQ: SAP HANA Compression

3258852 HAN-DB-ENG-BW No reorg plan generates by reorg_generate for SID table /<bw_prefix>/S*

2396601 HAN-DB How to change the partitioning information for a table during the DB migration to HANA

2014562 CA-LT-SLT FAQ: SAP HANA LT Replication Server (SLT)

2698617 HAN-DB-ENG How to increase the total number of partitions of an already hash partitioned table in SAP HANA

3144207 HAN-DB-ENG /STTP/SNR_LIST table partition on SAP HANA

3034420 HAN-DB Cannot re-create partition in DAGPTM

3084704 HAN-DB Manual partitioning of BW tables on SAP HANA database

2088971 HAN-DB-MON How-To: Controlling the Amount of Records in SAP HANA Monitoring Views

3029040 HAN-DB Add a new range partition on the first level into a multi-level-partitioned table

2800028 HAN-DB FAQ: SAP HANA Optimizer Statistics

3039026 HAN-DB [2594] DynamicRangePartitioning error

2209687 CA-LT-SLT SLT HANA target table Source Table Has More Than 2 Billion Records

3026988 HAN-DB ABAP Dump at partitioning on HANA 1.0

2800007 HAN-DB FAQ: SAP HANA Temporary Tables

2890332 HAN-DB Table re-partitioning failed with error "Data receive failed"

2169283 HAN-DB-ENG FAQ: SAP HANA Garbage Collection

2968794 HAN-DB-ENG SAP HANA Mini Check Alert: M0512: Hash partitioning on multiple columns

2666775 HAN-DB-ENG DML Operations through SAP Replication Server (SRS) to HANA are sub-optimal

2570371 HAN-DB-ENG FAQ: SAP HANA Execution Engine (HEX)

2952826 HAN-DB-HA Perform table partitioning on HANA primary site requires additional steps on secondary site?

2528241 HAN-DB Partitioning of tables replicated by SLT to SAP HANA database

2942115 HAN-DB-MON Size of delta storage of column-store tables alert: CDPOS table

2942131 HAN-DB-ENG How to check the progress of an ongoing partitioning activity?

2313619 HAN-DB-MON How-To: Generating and Evaluating SAP HANA Call Stacks

2930379 HAN-DB How to increase the total number of partitions for CDPOS table

2915190 HAN-DB-NSE NSE: feature not supported: modifying partition property for non-HETEROGENEOUS partitioned table

2875820 FIN-CS SAP S/4HANA Group Reporting On-Premise Performance - Collective note

2911712 HAN-DB Pool/PersistenceManager/PersistentSpace/DefaultLPA/DataPage grows during delta merge

2887270 HAN-DB-MON How to deal with metric "Record Count of Column Table Partitions"

2800008 HAN-DB-ENG-TXT FAQ: SAP HANA Fulltext Indexes

2340450 HAN-DB FAQ: SAP HANA Table Replication

2699939 HAN-DB SAP HANA Emergency Suitcase

2803209 BC-DB-HDB-SYS Client copy failed with error "Search result size limit exceeded"

2057046 HAN-DB-ENG FAQ: SAP HANA Delta Merges

1999880 HAN-DB-HA FAQ: SAP HANA System Replication

2222217 HAN-DB How-To: Troubleshooting SAP HANA Startup Times

2753417 HAN-DB-ENG-BW BW Data Load fails for PSA table with error "SQL code: 2048" occurred while accessing table "/BIC/xxxxxxxxxxx" ...The table has no OTHERS part...

2416490 HAN-DB FAQ: SAP HANA Data Aging in SAP S/4HANA

2100040 HAN-DB-PERF FAQ: SAP HANA CPU

2689405 XX-SER-MCC FAQ: SAP S/4HANA Performance Best Practices - Collective Note

1999930 HAN-DB FAQ: SAP HANA I/O Analysis

1998599 HAN-DB How-To: Analyzing high SAP HANA Memory Consumption due to Translation Tables

2212518 HAN-DB-ENG HANA error maximum number of rows per partition reached

2572224 HAN-DB-PER How-To: Repairing SAP HANA Tables

1999998 HAN-DB-PERF FAQ: SAP HANA Lock Analysis

2399990 HAN-DB How-To: Analyzing ABAP Short Dumps in SAP HANA Environments

2516035 EPM-BPC-NW BPC model with more than 2 billion records - BPC NW /HANA

2100009 HAN-DB-ENG FAQ: SAP HANA Savepoints

2000002 HAN-DB-PERF FAQ: SAP HANA SQL Optimization

2116157 HAN-DB FAQ: SAP HANA Consistency Checks and Corruptions

2222200 HAN-DB FAQ: SAP HANA Network

2380176 HAN-DB FAQ: SAP HANA Database Trace

1999997 HAN-DB FAQ: SAP HANA Memory

2119087 HAN-DB How-To: Configuring SAP HANA Traces

2222277 HAN-DB-PER FAQ: SAP HANA Column Store and Row Store

2222250 HAN-DB-PERF FAQ: SAP HANA Workload Management

2154870 HAN-DB How-To: Understanding and defining SAP HANA Limitations

2147247 HAN-DB-MON FAQ: SAP HANA Statistics Server

2114710 HAN-DB-MON FAQ: SAP HANA Threads and Thread Samples

2100010 HAN-DB-ENG SAP HANA: Popular Misconceptions

1999993 HAN-DB-MON How-To: Interpreting SAP HANA Mini Check Results

1910140 HAN-DB-MON How to Handle Alert 20 ‘Table growth of non-partitioned column-store tables’

2053330 HAN-DB-MON FAQ: Operations Recommendation on SAP HANA Alerts

2374652 HAN-DB-MON Handling Very Large Data Volumes in SAP BW/4HANA

3007026 FI-RA-IP Partitioning of fast growing tables in SAP RAR Inbound Processing

2960756 SD-BF-MIG VBFA Migration HASH Partitioning optimization

2916672 HAN-DB Indexserver Crash at JoinEvaluator::mergeDictsAndDocs When Executing a TREXviaDBSL Call

2700008 HAN-DB Indexserver Crashes with SIGNAL 11 at ptime::Transaction::preabort_for_slave() during recovery

2475971 HAN-DB Client Copy on SAP HANA Running Very Long Time

2418299 HAN-DB SAP HANA: Partitioning Best Practices / Examples for SAP Tables

2259038 MM-IM-GF-MIG S/4HANA: Partitioning of table MATDOC