ENERGEX uses Oracle Primavera to forecast network projects over short, medium, and long time horizons. They extract data from Primavera using APIs to connect it to other systems and tools. Due to the large number and value of projects, extracting ROI from Primavera requires optimizing for memory usage and database performance. Potential solutions include using the Enterprise Reporting Database, job services, scripting, splitting projects across the structure, and upgrading to 64-bit.
How to Troubleshoot Apps for the Modern Connected Worker
Insync10 anthony spierings
1. Heavy duty Oracle Primavera usage in enterprise environments: maximising ROI Anthony Spierings ENERGEX 16 August 2010 The most comprehensive Oracle applications & technology content under one roof
One solution is to bypass Job Services and to get the required information directly from the database. There is, however, a small problem; particularly when dealing with time-series data. The Primavera application makes clever use of the concept of logical data. We define logical data as information that can be reconstructed logically. This reconstruction is often done on the fly. Consider the following equation; If we wanted to store this equation inside the database, we only need to store n 1 and n 2 inside the database. When we retrieve these two values, we can logically reconstruct n 3 (as n 1 + n 2 ) on the fly. As mentioned before, Primavera makes extensive use of logical data. Some of the time-series data that we were after simply does not exist inside the database. It is reconstructed by the desktop client, web client, or Job Services when the project is loaded into memory. It is theoretically possible to reverse engineer the calculations using the information inside the database, but this was beyond our technical capability and resources available at the time. Logical data is sometimes called “virtual data” or “non-persistent” data. We define time-series data as information that has temporal ordering. For example a monthly cash flow forecast.
The impact of splitting up the jobs into smaller chunks is a reduction in CPU and memory usage. Figure 14 shows the CPU load on the Job Server XBNEWAS06. This snapshot was taken during the week from Sunday, 11 July 2010 to Sunday, 18 July 2010. The higher CPU usage is attributable to improved database I/O performance (a separate exercise that is discussed later). Improving database performance meant that CPU performance is now a constraint on performance. What is perhaps more instructive is the graph of available memory on the server as shown in Figure 15. This virtual server has 4GB of memory and 4GB page file. The assumption is that Primavera’s memory usage is now down to 0.79G of memory (3.45G – 2.66G). Recall that XBNEWAS18 has been replaced by XBNEWAS06 for Job Services.