ACDOCA is the most critical and data-heavy table in S/4HANA. As business volume grows, a low partition count leads to:
- Poor parallelism
- Longer financial close cycles
- High memory pressure during heavy jobs
- Slower reporting and analytics
Scaling partitions from 4 to 12 improves CPU utilization, memory distribution, and runtime of finance workloads. But repartitioning is a high-impact operation and must be executed in a controlled and technical manner.
Step 1 – Pre-Checks
Before touching ACDOCA:
- Ensure system health in:
- Check available memory:
System RAM Statement MemoryQAS~1 TB400 GBPPD~1.8 TB300 GBPRD~3.8 TB300 GB
- Decide whether temporary VM scale-up is required based on runtime vs cost.
Step 2 – Mandatory Parameters (Exact Names)
indexserver.ini → [partitioning]
split_threads = 64
Controls how many threads are used during repartitioning.
global.ini → [memorymanager]
statement_memory_limit = 400 GB
total_statement_memory_limit = 400 GB
Protects system memory during long-running ALTER.
Step 3 – Scale-Up Strategy
Temporary scale-up reduces runtime significantly:
SystemBase RAMTemporary VMQAS~1 TBM64sPPD~1.8 TBM96PRD~3.8 TBM128m
Always downscale after successful repartitioning.
Step 4 – Runtime Comparison (4 → 12)
SystemThreadsStatement MemoryRuntimeQAS64400 GB7–8 hoursPPD64300 GB~7.65 hoursPRD64300 GB~5:03:49
Scale-up + correct parameters saves hours.
Step 5 – Repartition Command
Step 6 – Execution Method (Very Important)
Initial partitioning can be done via Studio wizard. Repartitioning must be done using ALTER command only.
Avoid Studio GUI for long-running ALTER:
- Session timeouts
- IDE disconnects
- You lose visibility though job continues
Best practice: Run from DB host using hdbsql:
nohup hdbsql -u <DBUSER> -d <DBNAME> -A -j -C \
"ALTER TABLE 'SAPHANADB'.'ACDOCA' PARTITION BY HASH (BELNR) PARTITIONS 12;" &
Why:
- nohup → survives logout
- & → runs as background job
- hdbsql → stable for long execution
Step 7 – Monitoring & Verification
Check status:
SELECT * FROM M_TABLE_PARTITION_OPERATIONS WHERE TABLE_NAME = 'ACDOCA';
Verify partition layout:
SELECT PART_ID, PARTITION_SPEC, RECORD_COUNT FROM TABLE_PARTITIONS WHERE TABLE_NAME = 'ACDOCA';
Optional runtime statistics:
SELECT * FROM M_TABLE_PARTITION_STATISTICS;
Final Checklist
- Memory tuned
- Threads configured
- VM scaled
- ALTER executed via hdbsql + nohup
- Status monitored via SQL
- VM scaled back
Conclusion
Repartitioning ACDOCA is not just a DDL change — it is a controlled engineering operation. With the right parameters, execution method, and monitoring, you can:
- Reduce runtimes by hours
- Avoid production risk
- Make ACDOCA future-ready
Use the attached infographic as your one-stop technical reference for every ACDOCA repartitioning project.
