By JeffG-Oracle on May 22, 2015
Worksheet performance. There are dozens of notes. It can be challenging to find the best approach.
- If you are on 184.108.40.206 or greater, see the following three notes. Upgrade to the latest version of TABLE_REORG. Run TABLE_REORG with the 'T' option and review the suggestions in the LOG_TABLE_REORG table.
- Demantra TABLE_REORG procedure. Did you know that TABLE_REORG has replace rebuild_schema mad rebuild_tables?(Doc ID 2005086.1)
- Demantra TABLE_REORG Tool New Release with Multiple Updates! Partitions, DROP_TEMPS and More! 220.127.116.11 to 12.2.x.(Doc ID 1980408.1)
- If you have an error: Demantra table_reorg Procedure Failed ORA- on sales_data mdp_matrix promotion_data How do I Restart? rupd$_ mlog$_ I have Table cannot be redefinitioned in the LOG_TABLE_REORG table(Doc ID 2006779.1)
I would consider these notes to be the best regarding worksheet performance:
- Oracle Demantra Worksheet Performance - A White Paper (Doc ID 470852.1)
- Oracle Demantra Worksheet Performance FAQ/TIPS 7.3+! (Doc ID 1110517.1)
- Demantra 12.2.4 Worksheet Performance Enhancements Parameter dynamic_hint_enabled, Enable Dynamic Degree of Parallelism Hint for Worksheets.
- Development Recommended Proper Setup and Use (Doc ID 1923933.1)
- Demantra Development Suggested Performance Advice Plus Reference Docs (Doc ID 1157173.1)
- Oracle Demantra Worksheets Caching, Details how the Caching Functionality can be Leveraged to Potentially Increase Performance (Doc ID 1627652.1)
- The Column Prediction_Status, MDP_Matrix and Engine. How are they Related? Understand Prediction_status Values (Doc ID 1509754.1)
Demantra Gathering Statistics on Partitioned Objects Oracle RDBMS 11gR2 (Doc ID 1601596.1)
- Demantra 11g Statistics new Features and Best Practices Gather Schema Stats (Doc ID 1458911.1)
I would review all parameters mentioned in the docs above and:
1. Monitor the workstation memory consumption and CPU utilization as the worksheet is being loaded.
* You may have to adjust the memory ceiling for Java
2. Manage MDP_MATRIX. Are there dead/unused combinations? When running the engine, you can manage the footprint of the input. If MDP_MATRIX
is carrying sizeable dead combinations and/or entries without a matching entry in SALES_DATA, you are increasing processing load. Check out
note 1509754.1. The attachment explains the principle.
3. Using the notes above, can you cache? Can you use filters? Can you use open with?
A series can be cached, aggregated by item and cached in the branch_data_items table. This improves performance of worksheets that are aggregated
across locations and that do not have any location or matrix filtering.
4. Run the index advisor. Does it suggest additional indexes?
5. If you do not have the index advisor, produce an AWR. The AWR should be taken when the user opens the worksheet. For example, start the AWR process.
Wait 10-15 minutes. Tell the user to open the worksheet. After the open succeeds, wait 10 minutes. Stop the AWR process. What are the top SQLS?
What are the contentions?
6. Do you have your large tables on their own tablespace? This means each large table has a tablespace to its self. Each large index has a
tablespace to its self.
7. The worksheet is retrieving rows to display. Is there row chaining causing multiple block reads? That should be revealed in the AWR or run the
8. Worksheet design is important. The worksheet designers setup what they need. However, that does not mean that the worksheet design blends well
with available processing capabilities. Know the forecast branch health. I think this is discussed in 1509754.1. The following SQL reveals the
select level_id,count(*) from mdp_matrix
where prediction_status = 1
group by level_id
order by level_id
If you have a branch that is 100000 and remaining branches at 5000 and 10000 that is a problem. That would point to a setup/design issue.
Meaning that if you have branch as a level and it just so happens that 1 branch indeed has 100,000 and the other 2 branches account for smaller
volumne, 5000 and 10000, the chosen levels of the worksheet need to be revisted. Perhaps a level lower than branch is better suited to
processing the data. While this and #2 above are probably out of your control, it will help explain the worksheet loading and engine processing
9. Reduce the amount of memory that your worksheet selects:
- Remove series if possible
- Reduce the span of time
- Apply filters
10. Review all server and client expressions. Are they affecting performance?
11. Run DROP_TEMPS