Implementing Oracle’s® Primavera™ P6 in an enterprise or global environment is typically a costly and time-consuming endeavor and should be carefully planned with specific business goals in mind.
After many years of use and hundreds of projects later, however, a Primavera™ P6 Production database if not properly managed can become a muddy mess of global information used to group, sort, report, collect performance, and support global change. The maintenance of a Primavera™ P6 database is more than just adding users and creating projects. It takes careful consideration prior to implementation as to how the application will be used, how often external information will be imported, how data archival will be managed, how the global data will be configured and maintained, just to name a few.
This paper will provide some best practice recommendations which can be used to manage a Primavera™ P6 Production environment and help maintain order and avoid the chaos.
- Provide a minimum of two Primavera™ P6 databases (databases in a Microsoft® SQL Server or tablespaces in an Oracle® server) for the Production environment. One database meant to contain the production data and one to use as an acceptance or ‘cleansing’ area. This will help prevent pollution of the production database with non-production global data such as codes, calendars, resources, and user defined fields that could inadvertently be imported from external Primavera™ P6 .xer or XML files.
- Maintain separate Production databases for managing different types of projects. An example would be Turnaround versus Capital Projects. Turnaround resources and calendars are typically dedicated to specific events whereas Capital Projects will use an entirely different set of resources, calendars and codes. Management of data in a single database for these two distinctly different project types is cumbersome. Training should also take place in a separate database and not in a Sandbox Enterprise Project Structure (EPS) node in Production.
- Utilize intelligent, also known as ‘smart’ coding, for global data, project IDs and activity IDs. An example would be to use TA_ for all managed turnaround activity codes and use Project IDs containing the turnaround unit(s) acronym and year of the event. Any of this global data should be locked down and managed through a formal change control process.
- Limit the use of user defined fields (UDFs) to support global change or indicators. UDFs are user editable fields and as such can be changed. Try to not utilize for project critical data such as equipment numbers or other data that is more suited to activity coding since you are one key click away from wiping out information associated with that activity. Also try to control the growth of the number of UDFs by creating a subset sometimes referred to as ‘Z’ fields. These ‘Z’ fields could be used for temporary data open for general use but would be cleansed periodically to manage growth and database performance impacts. A UDF text field is 255 characters long no matter how many characters are actually used (e.g., a two character value still takes up 255 characters in the database table) in the field.
- Understand that the management of Primavera™ P6 users in the database is essential not just from a data security and access perspective but also from a licensing perspective. Primavera™ P6 is predominantly sold on a per-user license basis and if a 25 user license pack is purchased, then by license agreement, no more than 25 users can be logged into the production database at any one time. Proper management of user licensing is not only needed for legal purposes but can also help prevent purchasing more licenses than needed.
- Managing the list of code and values, resource/role dictionaries, and calendars can for the most part be done from the Primavera™ P6 client or Primavera™ P6 Web interface. However managing the relationship of this data with the individual projects and activities would be extremely complex if there were thousands of activities and associated coding and resource assignments. This knowledge is best gathered from direct SQL queries to the data residing in the Primavera™ P6 database. Examples of these queries can be found in the My Oracle Support* knowledgebase.
- Keep in the loop on patches that are occurring to the Production environment infrastructure; in particular the database servers and web application servers. Even though these patches and updates are not happening in Primavera™ P6 they can cause inadvertent impacts to Primavera™ P6. Java Runtime Engine (JREs) updates are notoriously finicky and are by no means as backward compatible as they are claimed to be. Keep cognizant of the tested configuration of the particular Primavera™ P6 version and fully test updates prior to allowing them to be rolled into production.
- Create a concise data backup and archival strategy during the course of the implementation and prior to rollout. Too often backing up of data is strictly thought of as a DBA concern and no further thought is made as to what happens if you lose or corrupt a project, critical layout or report and the only way to recover these is to do a full database recovery. This is both time consuming and a heavy impact on other users in the database especially if hours or days’ worth of work is lost across the user community. Create a simple file structure on your laptop or better yet in a SharePoint™ repository to export and store your projects, layouts and reports in case you need to recover from a corruption.*https://support.oracle.com
