ACDOCA Repartitioning in SAP S/4HANA...!!!

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

ALTER TABLE "SAPHANADB"."ACDOCA" PARTITION BY HASH (BELNR) PARTITIONS 12; 

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.