Fix Your Primavera P6 Project Settings In Minutes

We recently had a support call from a client that started having performance issues with their P6 database during the pre-work phase of their turnaround. We looked at the Oracle 11.2.0.4 enterprise database and found a massive amount of archive logs being chewed up. In fact, it was on a scale of 1-2 GB of logs within 2-5 minutes on average. With that kind of volume it would not take long for a server to receive the dreaded Oracle error message ORA-00257: archiver error. When this happens the database usually needs more space on the device where the archive log files are stored, which results in the database not allowing any more transactions until the issue is corrected.

If the client had been running Emerald’s Primavera In-A Box, a notification would have alerted them when they were running out of drive space and the archive remediation could have taken place prior to the database being inoperable. In this case, the client’s system implemented Netapp storage with Cisco servers running VMWare and Windows operating system. We asked ourselves “what could generate this kind of archive volume”?

Yes, Oracle or other tools exist to monitor this scenario, but in a busy world this kind of monitoring get classified as “nice to have”. The resource responsible in this scenerio never had time to complete the monitoring task.

What does a decision like this cost an organization? Well it depends, but we do work with companies that run Primavera where downtime is not an option. Costs range from hundreds of thousands to a few million dollars depending on size and scope of projects being managed within the system.

It turns out, by mistake, all the archived projects and some of the currently active projects had a flag to publish to the extended schema every 15 minutes. We corrected the issue immediately by 3 simple steps:

1. Extract project preferences into P6-Loader Excel format
2. Review and correct the publish and summarize settings for validity relevant to current projects
3. Load corrected P6-Loader Excel file back into P6 to update settings automatically and resolve the issue

5 minutes after the P6-Loader completed the upload the incorrect archive file generation stopped and regular operations resumed (200MB of logs within a 4 hour timeframe).

If you don’t have Emerald’s Primavera In-A-Box solution when undertaking a turnaround project at least the P6-Loader can correct Primavera P6 settings and structures quickly when an issue arises.