Performance and RDBMS Tuning and Maintenance
By JeffG-Oracle on Feb 27, 2012
Demantra is a Data Base resource intensive application.
- Evident from large implementations
- Large-scale implementations are global solutions across multiple regions or
retailer oriented store-level solutions - Require very large demand data
repositories storing billions of data points.
Common Demantra Performance issues
- Poor worksheet response times
- Longer Batch Engine run times
- Extended Simulation runs
- Prolonged Data loads
- Slow running user updates
These issues can be addressed by appropriate DB setup and tuning activities
This customer has been live on a Demantra VMI implementation and suddenly reported worksheet performance issues.
Sales_Data was ~32M records, non-partitioned
Analyze_Schema was not being run
Did a chained row count after Analyze_Schema – 48%
Recommended Rebuild_schema and worksheet performance improved 60% on average
This is a Demantra DM/PTP/DSM implementation. Just before UAT customer loaded full volume of Sales history,
Promotion and Settlement data and started experiencing serious worksheet performance issues.
MDP_Matrix=1.5M; Sales_Data=30M; Promotion_Data = 22M;
- CBO parameter changes
- Relocating null and empty columns in very large tables at the end of the row
- Sales_Data partitioning
- Reorder of Data by PK
- Worksheet specific Indexes
Performance Improvements reported:
Series Config Changes, 21%
GL Data Trim, 8%
Reorder Data by PK, 32%
Worksheet Cache Refresh, 73%