Tutorial · 2026

SAP HANA Large Table Partitioning: A Production Field Guide

When to partition large SAP HANA tables: range vs hash vs round-robin, online ALTER TABLE lock behavior, backup impact, and verification via persistence stats views, all doc-checked 2026-11-08.

advanced 16 min read Updated Nov 8, 2026
Contents

Every claim below comes from official SAP Help Portal (SAP HANA Cloud, QRC 3/2026, and SAP HANA platform edition 2.0 documentation), Microsoft Learn, or the public SAP Knowledge Base Article preview endpoint — all accessed on 2026-11-08. Where the documentation is silent, we say so explicitly and you must verify in your own system.

Partitioning is one of the most mis-quoted topics in SAP HANA operations. Blogs circulate a “>50 million rows, then partition” rule of thumb and SAP Note numbers that, on inspection, often do not say what people claim. We re-read the current documentation and re-verified the cited notes through the public KBA preview endpoint; below is what is documented, what is folklore, and what you must test in-system.

When Should You Partition — the Rule of Thumb vs. the Official Position

What the documentation does NOT say

Neither the SAP HANA Cloud Administration Guide nor the platform Administration Guide publishes a row-count threshold such as “partition above 50 million rows” — we searched both document sets on 2026-11-08 and found none. The 50M figure is community folklore, not SAP guidance. Microsoft Learn likewise has no page prescribing HANA partitioning thresholds for Azure; only deployment, HA and backup docs exist there. Azure-specific partitioning guidance is 未公开 (unpublished): validate any rule in your own workload.

What the documentation DOES say as reasons to partition

The Table Partitioning overview pages for HANA Cloud and for the HANA 2.0 platform give a consistent list of motivations, and they are worth quoting precisely:

  • Hard size limit. “A non-partitioned table cannot store more than 2 billion rows… Each partition must not contain more than 2 billion rows.” The only hard row-count figure in the product documentation; the kernel’s own margin is visible in KBA 2212518, whose indexserver traces show maximum allowed record count 2100000000, and DML fails with maximum number of rows per partition reached (SQL code 2055 on ABAP).
  • Scale-out load balancing. “Partitioning is typically used in multiple-host systems, but it may also be beneficial in single-host systems.” Rows are distributed across hosts so queries run against local partitions; in a scale-out system a table that cannot be partitioned is also a table that cannot spread.
  • Parallelization. Partitions let “several execution threads” work on one table.
  • Partition pruning. With static (and dynamic, for aging tables) pruning, queries with predicates on the partitioning column avoid accessing or even loading unneeded partitions from disk.
  • Better delta merge behavior. “If data is being modified on only certain partitions, fewer partitions will need to be delta merged and therefore performance will be better” — the classic case being a fact table where only the current period is hot.
  • Explicit lifecycle handling. Add a partition for the upcoming month, drop or archive a closed one, move a partition between hosts.

SAP HANA Cloud ships a Partition Advisor that turns the “when” question into configuration: it analyzes “table properties such as the current partitioning specification, the number and type of columns, the number of rows, how often and access predicates” against configurable, per-table thresholds — MIN_ROWS_FOR_PARTITIONING, REPARTITIONING_THRESHOLD (max rows per partition before repartitioning) and INITIAL_PARTITIONS. That is the closest official answer: the threshold is what you configure, not a fixed SAP number. The advisor covers up to 100 tables per request and needs a dedicated user (never DBADMIN): CATALOG READ for recommendations, PARTITION ADMIN to apply them; BOOLEAN partition columns are unsupported.

To modify partitions you need the ALTER object privilege on the table or the PARTITION ADMIN system privilege, which per the platform guide lets the holder “partition a table, move or merge partitions”.

Choosing a Scheme: Range, Hash, Round-Robin, Composite

Partitioning applies to column-store tables: the overview defines table partitioning as splitting “tables in column storage into multiple sub-tables (partitions)” along rows. All the syntax below is from the current SQL Reference and Administration Guide pages.

RANGE — for time-based access patterns

Range partitioning maps a partitioning expression (a column, or YEAR(), MONTH(), HOUR() functions of a date column) to disjoint value intervals. Supported range column types include STRING, NVARCHAR, the integer family, DECIMAL(p,s), DATE, TIMESTAMP, SECONDDATE, FIXED and RAW. Date partition intervals accept YYYYMMDD, YYYY-MM-DD and YYYY/MM/DD formats.

-- Monthly range-partitioned activity table (syntax from the cloud SQL Reference)
CREATE COLUMN TABLE ACTIVITY (
  ACT_ID      BIGINT NOT NULL,
  CREATED_AT  DATE   NOT NULL,
  CUST_ID     BIGINT,
  AMOUNT      DECIMAL(15,2),
  PRIMARY KEY (ACT_ID, CREATED_AT)
)
PARTITION BY RANGE (MONTH(CREATED_AT))
(
  PARTITION '202601' <= VALUES < '202602',
  PARTITION '202602' <= VALUES < '202603',
  PARTITION '202603' <= VALUES < '202604',
  PARTITION OTHERS
);

Two documented mechanisms make range partitioning practical for lifecycle data:

  • Dynamic range partitions. PARTITION OTHERS DYNAMIC [THRESHOLD <n>] auto-creates partitions instead of letting OTHERS grow. Beware the split-brain default: 10,000,000 rows in the cloud documentation vs 100,000,000 rows in the platform 2.0 documentation. On the platform, dynamic ranges work only for single-level RANGE (plus X-RANGE second level); INT is not supported for dynamic intervals, and intervals longer than 19 characters need AS DECIMAL(38).
  • Time selection. Aging workloads can flag one partition as “current” (PARTITION VALUE = '00000000' IS CURRENT on a leading NVARCHAR(8) column) and control storage per partition class: FOR NON CURRENT PARTITIONS UNIQUE CONSTRAINTS ON|OFF (default OFF — uniqueness checked only in the hot partition, a real lever for BW-type loads) and FOR DEFAULT STORAGE {ALL|NON CURRENT} PARTITIONS {PAGE|COLUMN} LOADABLE to push cold partitions to page load. Time selection is documented for single-level RANGE, RANGE-RANGE and second-level HASH-RANGE — not for HASH-HASH or ROUNDROBIN-RANGE.

HASH — for skew-proof load balancing

Hash partitioning “is used to distribute rows to partitions equally for load balancing and to overcome the 2 billion row limitation” and “does not require an in-depth knowledge of the actual content of the table” — pick enough columns for an even spread. Documented hash types cover dates/timestamps, integers/decimals, BOOLEAN, VARCHAR/NVARCHAR and VARBINARY (on the platform also memory LOBs such as CLOB/SHORTTEXT, not disk LOBs).

-- Hash on two columns; if a primary key exists, all partitioning
-- columns must be part of the key (so the uniqueness check stays local)
CREATE COLUMN TABLE MY_TABLE (
  a INT, b INT, c INT,
  PRIMARY KEY (a, b)
)
PARTITION BY HASH (a, b) PARTITIONS 4;

The PK restriction has a documented exception: PARTITION BY HASH (...) PARTITIONS 1 imposes no primary-key constraint — useful as a staging trick to give a table a partition structure without splitting data.

ROUNDROBIN — the trap everyone falls into

Round-robin assigns rows “to partitions on a rotation basis”, needs no partitioning columns and — critically — “the table must not have primary keys”. SAP is blunt about the downside: “Hash partitioning is usually more beneficial than roundrobin partitioning”, because (1) “the partitioning columns cannot be evaluated in a pruning step. Therefore, all partitions are considered in searches”, and (2) rows of semantically related tables may land on different servers, forcing remote retrieval. Round-robin buys load balancing and the 2-billion-row escape hatch at the price of a full-table scan across every partition on every lookup.

-- No primary key allowed
CREATE COLUMN TABLE EVENTS_RO (a INT, b INT, c INT)
PARTITION BY ROUNDROBIN PARTITIONS GET_NUM_SERVERS();

GET_NUM_SERVERS() (“the number of servers/partitions according to table placement”) is the sanctioned way to write landscape-independent scripts. A documented quirk is ROUNDROBIN PARTITIONS 1: one partition, full partition semantics — usable in TRUNCATE TABLE T_ROUNDROBIN_1 PARTITION(1) or ALTER TABLE T_ROUNDROBIN_1 MOVE PARTITION 1 TO 'host1:port2'.

Composite (two-level) partitioning

The SQL Reference documents nested schemes such as RANGE-RANGE, RANGE-HASH, HASH-RANGE, HASH-HASH and ROUNDROBIN-RANGE, on the platform up to three levels (e.g. RANGE-RANGE-RANGE). The canonical production pattern is range on time, hash inside each range — pruning by period, balanced load within it:

CREATE COLUMN TABLE SALES_LINE (
  INVOICE_DATE DATE NOT NULL,
  CUSTOMER_ID  BIGINT NOT NULL,
  AMOUNT       DECIMAL(15,2),
  PRIMARY KEY (INVOICE_DATE, CUSTOMER_ID)
)
PARTITION BY RANGE (MONTH(INVOICE_DATE))
(
  PARTITION '202601' <= VALUES < '202602',
  PARTITION '202602' <= VALUES < '202603',
  PARTITION OTHERS
)
SUBPARTITION BY HASH (CUSTOMER_ID) PARTITIONS 4;

Selection table

Your dominant problem Documented scheme to pick Why (per SAP docs) Main caveat
Queries filter by time/period; archive old data RANGE (optionally dynamic + time selection) Static/dynamic partition pruning; per-partition delta merge; add/drop partitions Watch uneven partition sizes (a “hot month” blows up one partition)
Scale-out CPU/IO balancing of a huge keyed table HASH (or HASH-RANGE) Equal distribution “does not require in-depth knowledge of content”; overcomes 2B limit; local uniqueness checks Partitioning columns must be inside the PK; no range pruning benefit
No usable PK/partition column; pure load spreading ROUNDROBIN Even rotation, zero design knowledge No pruning — every search touches all partitions; PKs forbidden; SAP itself prefers HASH
Time pruning and intra-period balance Composite RANGE + SUBPARTITION HASH Combines both mechanisms More complex repartitioning; check your level/type matrix (e.g. no time selection on ROUNDROBIN-RANGE)
Table approaching 2,100,000,000 rows/partition Partition at all costs (KBA 2212518) Hard limit per non-partitioned table and per partition Repartitioning a huge table takes hours (see below) — do it before you panic

Partitioning a Live Table: Costs, Locks and the “SPLIT” Question

The three documented costs of repartitioning

Turning an existing non-partitioned table into a partitioned one (or changing type/columns/count) is a redefinition. The Partitioning Operations page lists the price verbatim: “It takes a long time to run, up to several hours for huge tables. It has relatively high memory consumption. It writes everything to the log (required for backup and recovery).” That third sentence is the one people skip — we will return to it in the backup section.

Lock behavior — what is blocked and what is not

Same page, verbatim: “The repartitioning operation is a nonblocking process. Apart from a short period at the start as the partitioning process is prepared, it does not require an exclusive lock on the table. This means that you can execute SQL DML commands while repartitioning is running. However, DDL operations (table manipulations such as ALTER or DROP) are still blocked. At the end of the partitioning process, an exclusive lock is again required to apply repartitioning to delta contents.” So plan your window around two short exclusive-lock moments (start and end), not around the hours-long data movement.

The ONLINE keyword, documented identically on cloud and platform, is the explicit contract: “Allows you to partition an existing table without blocking DML while the DDL is executing. ONLINE is only supported for column-store, non-replicated tables, where specifying ONLINE performs an operation that only acquires a shared table lock. The operation is still serialized with other concurrent DDL operations on the table, including other ONLINE DDL operations.”

-- Repartition, and fail safely if the plan would move rows
ALTER TABLE T1 PARTITION BY RANGE (YEAR(C1))
(
  PARTITION 2024 <= VALUES < 2025,
  PARTITION 2025 <= VALUES < 2026,
  PARTITION OTHERS
)
CHECK NO DATA MOVE ONLINE;
-- SQL error 544 (ERR_RS_PARTITION) is raised if any row would change
-- partition, or persistent properties would change

CHECK NO DATA MOVE is the documented safety interlock: the statement aborts with error 544 instead of silently rewriting a huge table. Use it whenever the new partitioning spec is meant to be a no-op on existing data (for example, pre-creating next month’s partition boundary).

ALTER TABLE SPLIT PARTITION — what is actually documented

Be warned: the community text on this topic does not match the current manuals. In the SAP HANA Cloud QRC 3/2026 SQL Reference (both the non-heterogeneous and heterogeneous alter-partition clause pages) and the platform 2.0 SPS 08 non-heterogeneous clause page, there is no SPLIT PARTITION clause. Documented clause families: partition or redefine an existing table, add/drop range partitions, merge, move, dynamic-range properties, NUMA node preference, movable flags, load units, partition groups and names. The legacy HANA 2.0.00 Administration Guide PDF (public on help.sap.com) shows ALTER TABLE MY_TABLE ADD PARTITION 100 <= VALUES < 200, consistent with the documented ADD PARTITION clause.

So “splitting a partition” in supported SQL means one of:

-- 1) Non-heterogeneous (balanced) tables: REDEFINE the whole range spec,
--    finer-grained, e.g. split one half-year partition into quarters
ALTER TABLE T1 PARTITION BY RANGE (MONTH(C1))
(
  PARTITION '202601' <= VALUES < '202604',
  PARTITION '202604' <= VALUES < '202607',
  PARTITION '202607' <= VALUES < '202610',
  PARTITION '202610' <= VALUES < '202613',
  PARTITION OTHERS
);

-- 2) Heterogeneous (unbalanced, cloud) tables: ADD a partition into an
--    existing named range without touching the rest of the table
ALTER PARTITION WITH NAME ('P2026Q4')
  ADD PARTITION RANGE (MONTH(C1))
  (PARTITION '202610' <= VALUES < '202611');

-- 3) The reverse operation is documented too:
ALTER TABLE T1 MERGE PARTITIONS AT 'MyHost:30041';  -- merge onto one host
ALTER TABLE T1 DROP PARTITION '202412' <= VALUES < '202501';  -- one at a time
ALTER TABLE T1 MOVE PARTITION 1,2 TO 'MyServer1:34240', PARTITION 3,4 TO 'MyServer2' ONLINE;
-- PHYSICAL additionally moves LOBs on disk; without ONLINE you may only
-- move ONE partition to ONE host per statement

The kernel has split logic — KBA 2212518 shows a Split.cpp trace line during partitioning — but if any release exposes a literal ALTER TABLE … SPLIT PARTITION … statement, that is 需系统内验证 (to be verified in-system): probe the ALTER TABLE grammar on your own HANA before trusting blog code. Everything above is what the current public grammar documents.

Backup and Recovery Impact

Partitioning does not change what gets backed up — we found no documented partition-level backup or restore command in the current SQL Reference — but it changes how much red volume you generate:

  1. Repartitioning writes the entire table to the log. The documented cost sentence — “It writes everything to the log (required for backup and recovery)” — means a multi-hour repartition of a multi-terabyte table floods log backups. On Azure VMs streaming to Azure Backup, the documented 15-minute minimum RPO rests on log_backup_timeout_s: 900; a repartition saturates that pipeline, and point-in-time recovery must replay the extra logs — a longer replay tail for the window containing the operation.
  2. Size still dominates restore time. Microsoft Learn (updated 2026-07-23): “as databases grow in size, the time it takes to restore them becomes a factor when you’re dealing with streaming backups”, and Backint stream generation “can grow in proportion to the churn.” The same page documents the snapshot-based alternative (“instant backup and instant restore”), weekly full snapshots as mandatory per SAP recommendation, and scale-out support in preview (streaming only, unified backup chain). See our HANA backup and DR field guide.
  3. Partitioning does not shrink a full backup in any documented way. What it can ease is operational pressure: cheaper delta merges (fewer partitions merged) and page-loadable cold partitions. Test backup duration before/after in your own landscape; for the sizing baseline start from the deployment guide.

The honest summary: treat partitioning’s backup story as one of avoiding surprise log volume during repartitioning — schedule it like the data-center-scale DDL it is, and never skip log backup during the operation.

Verifying the Effect: the Persistence Statistics Views

M_TABLE_PERSISTENCE_STATISTICS — table level, read the fine print

The documented view “provides persistence summary statistics for tables”, with exactly these columns: SCHEMA_NAME, TABLE_NAME, DISK_SIZE (“total disk size, in bytes, of all of the table parts”), PAGE_COUNT, plus the BYTES_*/*_COUNT counters (BYTES_WRITTEN, BYTES_APPENDED, BYTES_READ, BYTESTREAM_WRITTEN, APPEND_COUNT, WRITE_COUNT, OPTIMIZE_COUNT, READ_COUNT, TRUNCATE_COUNT, COPY_COUNT). Two gotchas: there is no PARTITION_ID column — this view aggregates all table parts — and unfiltered access requires CATALOG READ (the view itself is granted to PUBLIC). Use it for before/after disk footprint:

SELECT schema_name, table_name, disk_size, page_count
FROM m_table_persistence_statistics
WHERE table_name = 'ACTIVITY';

M_TABLE_PERSISTENCE_LOCATION_STATISTICS — the per-partition view

For partition-level verification use M_TABLE_PERSISTENCE_LOCATION_STATISTICS (documented for the platform, with a cloud sibling): the same measures plus PARTITION_ID, HOST and PORT. The PARTITION_ID semantics are fully documented: sequential from 1; 0 for non-partitioned tables; -1 while the table schema is being modified — your live signal that a repartition is in flight.

-- Row/size distribution and host balance after partitioning
SELECT partition_id, host, port, disk_size, page_count
FROM m_table_persistence_location_statistics
WHERE table_name = 'ACTIVITY' AND schema_name = 'SAPAI'
ORDER BY partition_id;

-- Skew check: max/min partition size — the number that decides whether
-- your RANGE boundaries or HASH columns were the right choice
SELECT table_name,
       MAX(disk_size) AS max_part_bytes,
       MIN(disk_size) AS min_part_bytes,
       COUNT(DISTINCT partition_id) AS partitions
FROM m_table_persistence_location_statistics
GROUP BY table_name;

Close the loop against the advisor’s REPARTITIONING_THRESHOLD and the hard 2.1B ceiling: if a single partition creeps toward it, KBA 2212518 names the trace lines that fire first. For host placement use M_TABLE_LOCATIONS (referenced by the Partitioning Operations page); partition numbers for NUMA statements come from TABLE_PARTITIONS; the Partition Advisor docs list the full “System Views for Monitoring Partitions” set.

The Official-Guidance Status Check: SAP Note 2147216 and Friends

A widely circulated reference claims “SAP Note 2147216” as the partitioning guidance. We checked the KBA preview endpoint on 2026-11-08: 2147216 is titled “Error: A valid keycode to use the Business View Manager is not found”, for SAP BusinessObjects BI Platform 4.2/4.3/2025 (component BI-RA-CR) — nothing to do with HANA partitioning. Lesson: verify any note number at https://userapps.support.sap.com/sap/support/knowledge/en/<NUMBER>; the preview shows title, symptom, environment and keywords without an S-user login (full text stays login-gated).

What does exist and is relevant:

  • KBA 2212518 — “HANA error maximum number of rows per partition reached”: documents the exact error, the maximum allowed record count 2100000000 trace, the merge+optimize compression advice, and the Split.cpp partitioning trace. Platform edition, all versions. This is your 2B-limit runbook.
  • KBA 3361169 — “Table distribution/redistribution not creating the desired/expected reorg plan in SAP HANA”: for BW-on-HANA, tables in a table group must be redistributed together with identical partitioning, via CALL REORG_GENERATE/CALL REORG_EXECUTE with the plan inspectable in reorg_plan (OLD_PARTITION_SPEC/NEW_PARTITION_SPEC). It references Notes 2019973, 2374652, 1969700 and KBAs 3288401/2479785 — we verified only 3361169 itself; cite the others from this KBA’s See-Also list, not from memory.
  • Beyond these, we found no public SAP Note stating a universal partitioning best-practice rule for HANA; the authoritative material is the Administration Guide + SQL Reference pair cited throughout. If your Basis team quotes a different note number, run it through the preview endpoint before scheduling downtime against it.

FAQ

Q1: Is “>50 million rows” an official SAP threshold? No. Current SAP documentation publishes no row-count trigger; the only official numbers are the 2,000,000,000-row limit per non-partitioned table/partition, the dynamic-range defaults (10M cloud / 100M platform rows), and the Partition Advisor’s customer-configurable MIN_ROWS_FOR_PARTITIONING/REPARTITIONING_THRESHOLD. Use 50M as folklore, size your own threshold from query and delta-merge behavior.

Q2: Will partitioning make all my queries faster? No. Speedups come from pruning (predicates must hit RANGE partitioning columns), intra-table parallelism and cheaper delta merges on cold tables. Round-robin explicitly cannot prune — “all partitions are considered in searches” — and hash partitioning is a load-balancing tool, not a pruning tool.

Q3: Can I partition the table online at 2 a.m. without anyone noticing? DML keeps flowing during ONLINE repartitioning (shared table lock; start/end preparation phases aside), but DDL is serialized, non-replicated column tables only, and the whole operation writes everything to the log for hours. Budget maintenance window, log space and memory anyway; use CHECK NO DATA MOVE to fail fast with error 544 when the spec accidentally implies data movement.

Q4: Does ALTER TABLE … SPLIT PARTITION exist? Not in the current cloud QRC 3/2026 or platform 2.0 SPS 08 SQL Reference grammar. Split a range partition by redefining ranges (non-heterogeneous) or by ALTER PARTITION WITH NAME (…) ADD PARTITION RANGE (…) (heterogeneous). If a newer release adds a SPLIT clause, verify against your system’s grammar before propagating blog syntax.

Q5: Do backups get smaller if I partition? There is no documented partition-level backup/restore; the full database is still the unit. The documented partition-related backup effect is the one you want to manage: repartitioning “writes everything to the log”, inflating log backups and the point-in-time replay tail. On Azure, pair this awareness with Microsoft Learn’s streaming-vs-snapshot restore-time guidance.

Q6: My tables are SAP BW/ABAP-managed. Can I just ALTER TABLE them? No — for table groups, follow the redistribution process documented in KBA 3361169 (whole group together, identical partitioning across the group, plan via REORG_GENERATE, inspect reorg_plan before REORG_EXECUTE), and apply application-level guidance from SAP with login-gated notes your team can actually open.

Sources

All accessed and verified on 2026-11-08.

  1. SAP HANA Cloud Administration Guide — Table Partitioning: https://help.sap.com/docs/hana-cloud-database/sap-hana-cloud-sap-hana-database-administration-guide/table-partitioning?locale=en-US
  2. SAP HANA Platform 2.0 Administration Guide — Table Partitioning: https://help.sap.com/docs/SAP_HANA_PLATFORM/6b94445c94ae495c83a19646e7c3fd56/c2ea130bbb571014b024ffeda5090764.html?locale=en-US
  3. SAP HANA Cloud — Hash Partitioning: https://help.sap.com/docs/hana-cloud-database/sap-hana-cloud-sap-hana-database-administration-guide/hash-partitioning?locale=en-US
  4. SAP HANA Cloud — Roundrobin Partitioning: https://help.sap.com/docs/hana-cloud-database/sap-hana-cloud-sap-hana-database-administration-guide/roundrobin-partitioning?locale=en-US
  5. SAP HANA Cloud — Partitioning Operations: https://help.sap.com/docs/hana-cloud-database/sap-hana-cloud-sap-hana-database-administration-guide/partitioning-operations?locale=en-US
  6. SAP HANA Cloud — About the Partition Advisor: https://help.sap.com/docs/hana-cloud-database/sap-hana-cloud-sap-hana-database-administration-guide/about-the-partition-advisor
  7. SAP HANA Cloud SQL Reference — Non-Heterogeneous Alter Partition Clauses: https://help.sap.com/docs/hana-cloud-database/sap-hana-cloud-sap-hana-database-sql-reference-guide/non-heterogeneous-alter-partition-clauses?locale=en-US
  8. SAP HANA Cloud SQL Reference — Heterogeneous Alter Partition Clauses: https://help.sap.com/docs/hana-cloud-database/sap-hana-cloud-sap-hana-database-sql-reference-guide/heterogeneous-alter-partition-clauses?locale=en-US
  9. SAP HANA Platform 2.0 SQL Reference — Non-Heterogeneous Alter Partition Clauses (SPS 08): https://help.sap.com/docs/SAP_HANA_PLATFORM/4fe29514fd584807ac9f2a04f6754767/f7ae27ca1b954471a4e1a7feab2c24d7.html?locale=en-US
  10. SAP HANA Cloud SQL Reference — M_TABLE_PERSISTENCE_STATISTICS System View: https://help.sap.com/docs/hana-cloud-database/sap-hana-cloud-sap-hana-database-sql-reference-guide/m-table-persistence-statistics-system-view?locale=en-US
  11. SAP HANA Platform 2.0 SQL Reference — M_TABLE_PERSISTENCE_LOCATION_STATISTICS System View: https://help.sap.com/docs/SAP_HANA_PLATFORM/4fe29514fd584807ac9f2a04f6754767/2d7c6952032940b8ae06bb60766094cf.html?locale=en-US
  12. Microsoft Learn — About Azure Backup for SAP HANA databases on Azure VMs: https://learn.microsoft.com/en-us/azure/backup/sap-hana-database-about
  13. SAP KBA 2147216 (public preview) — Business View Manager keycode error (verified: unrelated to partitioning): https://userapps.support.sap.com/sap/support/knowledge/en/2147216
  14. SAP KBA 2212518 (public preview) — HANA error maximum number of rows per partition reached: https://userapps.support.sap.com/sap/support/knowledge/en/2212518
  15. SAP KBA 3361169 (public preview) — Table distribution/redistribution not creating the desired/expected reorg plan: https://userapps.support.sap.com/sap/support/knowledge/en/3361169
  16. SAP HANA 2.0.00 Administration Guide (PDF, public) — ADD PARTITION example: https://help.sap.com/doc/eb75509ab0fd1014a2c6ba9b6d252832/2.0.00/en-US/SAP_HANA_Administration_Guide_en.pdf