1. 先把这套环境说清楚：OEL 上跑 P6 EPPM 到底在装什么

P6 EPPM 在 OEL 上的安装，本质是把三块相互独立又强耦合的东西拼到一起：一个 Oracle 数据库撑着数据，一套 Java 中间件撑着应用，再加一份层层叠叠的应用介质把业务模块布上去。很多人第一次装的时候，脑子里只有一个模糊的印象——“装个软件”，结果在前面aming几十分钟、到部署环节才发现，前面数据库建库时的字符集选错、表空间没规划好、系统内核参数没调，后面全得推倒重来。我经手过几套从零搭建的项目管理平台环境，最惨的一次是数据库建完发现字符集不是 AL32UTF8，中文字段在 P6 Web 里显示成问号，最后只能删库重来——那一次让我彻底改掉了“先装起来再说”的习惯。

P6 EPPM 是工程行业里做进度计划、资源与成本管理的核心平台，它的使用场景非常具体：施工总承包单位的计划部门要把几千上万条活动编制成网络计划，项目部要按周更新实际进度，管理层要看里程碑偏差，商务口要拉资源曲线和费用曲线。这套系统天生就是“重数据库、重报表、多人并发”的形态，不是那种装个单机版就能用的轻量工具。所以它落在 OEL 上，最合理的形态是一台数据库服务器加一台应用服务器，规模再小也别把两者压在同一个操作系统实例里——这不是洁癖，是内存和 IO 抢得太厉害。

OEL（Oracle Linux）之所以成为这类环境的首选，道理很朴素：同一家厂商的数据库、中间件、操作系统，官方兼容性矩阵里写得明明白白，遇到问题翻文档不用在三家社区之间来回猜。而且 OEL 的内核和包管理跟主流企业级发行版同源，运维同事上手成本低，yum/dnf装依赖、配本地源都很顺手。相比之下，用非企业级发行版去跑 Oracle 数据库，官方支持层面会比较尴尬，出问题只能自己扛。

Prisma？不是。P6 EPPM 的核心组件可以这样拆：

• Oracle Database：存放全部业务数据，P6 会在里面建若干个职责分离的 schema，分别管应用元数据、项目私有数据、公共数据。
• Oracle WebLogic Server：P6 的应用容器，P6 Web、Team Member、Progress Reporter、Web Services、Integration API 这些模块都是以应用包的形式部署在 WebLogic 的域里。
• P6 EPPM 应用介质：安装程序本身，负责往数据库里灌初始结构和往 WebLogic 里布应用。
• BI Publisher / 报表组件：负责输出各类报表，很多单位第一次装完发现“报表打不开”，八成是这块没配通。
• 内容库：存放项目文档、附件之类的二进制内容。

这套组合决定了安装顺序必须是“操作系统 → 数据库 → 中间件 → 应用 → 配置校验”，任何一步跳过去，后面都会以更难懂的方式报错。适合读这篇的人，大概分两类：一类是要在一台干净的 OEL 上从零搭一套测试或生产环境的实施工程师，另一类是接手了别人装好的环境、想知道它到底是怎么长出来的运维。两类人关注点不同，但都需要知道每一步为什么这么做。

2. 动手之前先把资源账算清楚，别等装到一半才发现内存不够

装 Oracle 系的产品，最忌讳的就是“边装边看”。P6 EPPM 对资源的胃口不算夸张，但它的资源消耗是叠起来的：数据库的 SGA、WebLogic 的 JVM 堆、操作系统自身的缓存、再加上 P6 应用本身的线程池和连接池。我见过太多环境，机器给了 16G 内存，数据库吃掉 8G，WebLogic 起两个受管节点又各要 4G，系统剩下不到 2G，跑起来之后页面点一下要等十几秒，还以为是安装出错，其实是内存被榨干了。

2.1 内存与 CPU 的分配逻辑

我的经验算法是这样的：先定并发用户数，再倒推。P6 Web 的并发用户并不是一人一个线程，但每个活跃会话在 JVM 里都会占一块内存，加上连接池、缓存，一个中等负载的受管节点给 4G 堆是比较稳妥的起点。数据库侧，SGA 一般按物理内存的 40%~50% 给，但前提是应用不跟它抢。

上表是经验区间，不是官方硬指标。真实项目里我一般会在中型配置上再留 30% 余量，因为 P6 的“月末集中填报”是典型的尖峰场景——平时几个人用，月底那一周所有人都在更新进度、跑报表，压力能翻好几倍。

注意：不要用虚拟化平台的“超分”内存去跑这套东西。数据库的 SGA 一旦被宿主机换页，性能会断崖式下跌，而且这种问题从应用层看只会表现为“偶尔卡一下”，极难定位。

2.2 磁盘分区与表空间容量估算

磁盘这块更容易被忽略。P6 的数据库增长主要来自几个方向：项目活动明细（每个活动一行甚至多行）、资源与费用分配、审计与历史版本、以及附件内容。以我经手的一个中等规模项目库为例，2000 个项目的年度计划量、每个项目 500~2000 条活动，一年下来数据文件大概增长 20~40G，索引占的比数据还多。

我给的分区建议是/u01单独挂，数据库软件和归档日志分开；/u02给数据文件；如果预算允许，数据文件和归档日志最好落在不同的物理盘上。为什么？因为 P6 的批量更新是写很重的操作，归档日志和数据文件争同一块盘的 IO，表现出来的就是“保存按钮转圈”。

表空间的规划我习惯这样切：

• P6 业务数据表空间：单独建，不做自动扩展无上限，设定一个明确的上限值和告警阈值。
• P6 索引表空间：跟数据表空间分开，重建索引时不会把数据空间撑爆。
• 临时表空间：P6 跑大型报表和计划计算时临时段用得很凶，temp 文件给到 8G 起步。
• UNDO 表空间：批量更新时回滚段需求大，按经验给到 4G~8G。

2.3 内核参数与系统限制

OEL 上跑 Oracle 数据库，有几个参数必须提前写好，不然后面数据库实例都起不来或者起得很憋屈。kernel.shmmax要大于 SGA 大小，kernel.sem要满足数据库进程的信号量需求，fs.file-max和用户的nofile限制更是关键——WebLogic 打开的文件句柄数远超默认值，默认 1024 在高并发下会直接报 “Too many open files”。

# /etc/security/limits.conf 追加 p6admin soft nofile 65536 p6admin hard nofile 65536 p6admin soft nproc 16384 p6admin hard nproc 16384 # /etc/sysctl.conf 追加，按 32G 内存机器举例 kernel.shmmax = 17179869184 kernel.shmall = 4194304 kernel.sem = 250 32000 100 128 fs.file-max = 6815744 net.ipv4.ip_local_port_range = 9000 65500

改完sysctl -p生效，再用ulimit -a以目标用户身份确认一遍。这一步看着琐碎，但它是后面所有“玄学问题”的地基。

3. 系统底座：OEL 的初始化到底要做哪些事

我见过一种做法：为了省事，装系统时选“带 GUI 的完整安装”，把能勾的都勾上。这在小规模测试机上还行，生产环境上我是不建议的——包越多，依赖冲突的风险越大，尤其是 Oracle 系产品对某些基础库的版本很敏感，多装的东西反而容易成为隐患。我通常选“最小化安装”加“开发工具”组，再把缺的包单独补。

3.1 安装介质与最小化安装的取舍

最小化安装之后要补的包，我一般按这个思路准备：图形安装程序需要 X11 相关库，数据库和中间件需要compat-libstdc++、libaio、libnsl、glibc系列，另外还有unzip、bc、net-tools、bind-utils这些排查问题时离不开的小工具。P6 的安装程序是 Java 写的，所以本地还得有可用的 JDK 或者安装介质自带的运行时。

dnf install -y oracle-database-preinstall-19c dnf install -y unzip bc net-tools bind-utils libnsl libaio

oracle-database-preinstall这个包非常值得用，它会把用户、组、内核参数、limits 一次性配好，省掉大量手工核对。但要注意，它会创建默认用户和目录，如果你的环境里已经规划了不同的用户名，装之前先看清楚它会改什么，别把已有的配置覆盖掉。

提示：如果你是在内网环境，提前把 OEL 的本地源（ISO 挂载或内网镜像）配好。安装过程中依赖缺失是最常见的卡点，现场再去找包会非常被动。

3.2 用户、目录与权限规划

用户规划上，我坚持“数据库和应用分开用不同账号”。数据库用oracle这个约定俗成的账号，应用侧单独建一个账号（比如p6admin），两个账号分别属于oinstall、dba和它自己的应用组。这样做的直接好处是：应用侧出问题不会误伤数据库文件权限，审计时也能分清谁动了什么。

目录结构我习惯这样布：

/u01/app/oracle/product/19.0.0/dbhome_1 # 数据库软件 /u01/app/oracle/oradata # 数据文件 /u01/app/oracle/fast_recovery_area # 归档与备份 /u01/app/p6/weblogic # 中间件 /u01/app/p6/p6epm # 应用介质与配置 /u01/app/p6/domain # WebLogic 域

目录归属一定要在建库之前定好，chown -R和chmod -R 775做完之后再动手。我吃过一次亏：安装程序跑到一半提示某个目录不可写，回头改权限后重跑，结果中间状态残留，只能清空重来。

3.3 防火墙、SELinux 与时区

这三项是安装期的“隐形杀手”。SELinux 开着 enforcing 模式，数据库的监听和 WebLogic 的端口绑定都可能被拦；防火墙不放开端口，本机测试通、远程访问不通，很容易误判成应用没起来。

我的做法是：安装调试阶段把 SELinux 设成 permissive，上线前再根据实际情况决定是否恢复 enforcing 并配策略；防火墙按最小开放原则放行必要端口——数据库监听 1521、WebLogic 管理端口 7001、P6 Web 的 HTTP 端口 8000（或你自定义的端口）、以及报表组件的端口。时区统一设成业务所在地时区，并且确保数据库、操作系统、应用服务器三者的时区一致，不然 P6 里的日期字段会出现莫名其妙的偏移，这种问题排查起来极其磨人。

timedatectl set-timezone Asia/Shanghai sed -i 's/^SELINUX=.*/SELINUX=permissive/' /etc/selinux/config firewall-cmd --permanent --add-port=1521/tcp firewall-cmd --permanent --add-port=7001/tcp firewall-cmd --permanent --add-port=8000/tcp firewall-cmd --reload

4. 数据库层：P6 的“地基”怎么打才不留后患

P6 EPPM 对数据库的依赖非常深，它不是一个“能用就行”的数据库，而是一个对字符集、参数、权限都有明确要求的数据库。我在这一层见过的问题，比后面所有环节加起来还多。

4.1 数据库版本与字符集，两个不能将就的选择

版本选择上，跟着 P6 EPPM 版本的官方兼容矩阵走，别自己发挥。较新的 P6 版本基本都要求 19c 及以上，用低版本会卡在安装程序的预检查环节。真正要谨慎的是字符集：必须用 AL32UTF8。P6 支持多语言，项目名、活动名、WBS 名称里混着中英文是常态，用 ZHS16GBK 之类的字符集，一开始可能看不出问题，等到某天有人粘贴了一个特殊符号进去，整条记录就存不下了，报错信息还非常隐晦。

建库时我一般用 DBCA 的静默方式，把关键参数一次写进响应文件：

dbca -silent -createDatabase \ -templateName General_Purpose.dbc \ -gdbName p6db -sid p6db \ -characterSet AL32UTF8 \ -nationalCharacterSet AL16UTF16 \ -sysPassword "********" -systemPassword "********" \ -datafileDestination /u01/app/oracle/oradata \ -recoveryAreaDestination /u01/app/oracle/fast_recovery_area \ -recoveryAreaSize 20480 \ -memoryPercentage 45 \ -totalMemory 32768 \ -emConfiguration NONE

-memoryPercentage 45这个值是我在 32G 机器上的习惯配置，SGA 大概落在 14G 左右，给操作系统和 PGA 留足余量。如果数据库和应用部署在同一台机器上（不推荐但有时不得不这样），这个比例要压到 30% 以下。

4.2 初始化参数里必须调整的几项

建库只是开始，P6 上线前我一定会检查这几个参数：

processes和open_cursors这两项，改完必须重启数据库生效。我在一个项目上遇到过“用的人一多就报无法分配连接”，查了两天应用配置，最后发现是数据库的processes只给了 150。

4.3 P6 schema 的创建与校验

P6 EPPM 的安装程序会自动在数据库里创建几个 schema，分别负责应用元数据、项目私有数据、公共数据。安装过程中它会要求你提供数据库连接信息和一个具备建用户权限的账号，剩下的事它自己干。这里有几个细节值得说：

第一，表空间要提前建好。安装程序默认可能把对象塞进 USERS 表空间，这在测试环境无所谓，生产环境上数据、索引、大对象混在一个表空间里，后续维护会很痛苦。我会提前建好专用表空间，在安装程序的选项中指定。

第二，密码里的特殊字符要小心。有些单位要求密码包含@、$、#，这些字符在连接串、Shell 脚本、响应文件里都可能被解释，导致明明密码是对的却连不上。稳妥的做法是安装期先用字母数字组合，装完再改密码。

第三，安装完成后立即做一次连接验证，用sqlplus分别以几个业务 schema 登录，确认账号没被锁定、表空间配额正确。这一步花两分钟，能省掉后面几小时的排查。

5. 中间件与应用部署：P6 EPPM 安装程序怎么填

到这一步，很多人会松一口气，觉得“点下一步就行了”。实际上 P6 EPPM 的安装向导有几十个交互项，填错一个就可能出现“装完了但打不开”的局面。

5.1 JDK 与 WebLogic 的前置准备

P6 安装介质里通常包含 WebLogic 的安装程序，但 JDK 的版本要提前确认——不同 P6 版本对 JDK 的要求不一样，用错了在启动受管节点时会报版本不兼容。我一般会把 JDK 单独装在一个固定目录，比如/u01/app/p6/jdk，并设置好JAVA_HOME，这样后面所有组件都指向同一个 JDK，避免版本打架。

WebLogic 的域创建，P6 安装程序会引导你完成，但我建议在创建域之前就想清楚：用管理服务器单节点，还是管理服务器加受管节点。测试环境单节点够了，生产环境我强烈建议至少一个受管节点，把 P6 应用部署在受管节点上，管理服务器只做管理。理由很实际——P6 的重启、部署更新、日志排查都会方便很多，而且后续做多节点扩展时不用推倒重来。

目录规划上，域目录和数据目录分开放，日志目录单独挂。WebLogic 的日志增长速度快得惊人，管理服务器加受管节点，一天几百万行日志是常事，跟应用目录混在一起很容易把磁盘写满。

5.2 安装向导里那些关键交互项

P6 EPPM 安装程序走下来，有几个页面必须停下来想清楚：

数据库连接页：主机名、端口、SID/服务名、以及几个 schema 的密码。这里的主机名建议用 IP 或者能稳定解析的域名，别用localhost——后面如果换成受管节点部署，localhost会解析到错误的位置。

应用服务器配置页：域名、管理端口、管理员密码、SSL 端口。端口规划要避开系统已占用的端口，我习惯把 WebLogic 管理端口设成 7001，P6 Web 走 8000，并且提前用ss -lntp确认没被占用。

部署目标页：选择部署到管理服务器还是受管节点。这一项如果选错，后面调整起来非常麻烦，需要重新部署应用包。

内容库配置页：附件和文档存放的位置。这块我一般单独规划一个目录并做好备份策略，因为项目文档一旦丢了，业务方是真的会找上门。

注意：安装向导的每一步完成之后，先去看对应组件的日志，别等到最后一步才统一看。P6 的安装日志分散在多个位置，后面出问题时按时间顺序翻日志，能省掉大量猜测。

5.3 部署后必须做的几项配置

装完不等于能用。我列一下装完之后一定要动的配置：

• 数据库连接池：在 WebLogic 控制台里把 P6 数据源的初始连接数和最大连接数调到一个合理值。默认值往往偏小，用户一多就排队。我一般按“并发用户数的 1.5 倍”设最大连接数，同时确认数据库的processes足够容纳。
• JVM 参数：受管节点的堆大小、GC 策略要显式设置。默认的堆大小在中等负载下不够用，会频繁 Full GC，表现就是“页面每隔一阵卡几秒”。
• 邮件服务器：P6 的通知、密码找回都依赖邮件配置，不配的话相关功能静默失败，用户只会觉得“系统坏了”。
• 语言与区域设置：确认应用到数据库的语言配置一致，避免出现中文乱码或者日期格式错乱。
• 报表组件：单独配置数据源和访问地址，然后从 P6 Web 里点一次报表，确认整条链路通。

# 受管节点启动参数示例（在 setDomainEnv.sh 中调整） USER_MEM_ARGS="-Xms4096m -Xmx4096m -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=1024m"

6. 上线前的验证与调优：按层次往下打

我从不相信“装完能打开首页就算成功”。P6 这种多组件系统，必须按层次逐级验证，每一层都确认通了再往下走，否则出问题时根本不知道该怀疑谁。

6.1 逐层验证的顺序与手段

我的验证顺序是：数据库监听 → 数据库连接 → schema 可用性 → WebLogic 管理服务器 → 受管节点 → P6 应用首页 → 登录 → 创建测试项目 → 报表输出 → 附件上传。每一步都有明确的判断标准，不是“看着没报错”就算过。

这个表格我每次实施都带着，逐项打勾。有一次在一个环境上，前面六项全过，最后附件上传失败，查下来是内容库的目录权限问题——如果只验证到“能登录”，这个问题会等到用户第一次传文档才暴露。

6.2 应用侧与数据库侧的调优重点

调优这件事，我的原则是“先解决明显的瓶颈，别一上来就调参数”。明显的瓶颈包括：JVM 堆不够导致频繁 GC、连接池太小导致请求排队、数据库缺少必要索引导致大查询慢。这三项解决了，性能通常能提升一大截。

JVM 这块，我一般会打开 GC 日志观察一段时间，如果发现 Full GC 频繁且每次回收效果有限，说明堆确实不够或者有内存泄漏；如果 Young GC 频率很高但耗时短，那基本正常。数据库侧，P6 的大型报表查询会扫很多表，我会在业务高峰期用AWR报告看一下 TOP SQL，针对性地补充索引或者调整 SQL 提示。

提示：调优之前一定要有基线。先在典型场景下记录一组响应时间（比如打开项目详情、保存进度更新、生成月度报表），改完参数再测一遍对比。没有基线的调优全靠感觉，很容易越调越糟。

6.3 备份与回滚点

上线前必须做的一件事：完整备份一次。数据库做一次全备加归档，应用目录整体打包，WebLogic 域目录单独打包。这样万一上线后发现配置有问题，能在半小时内回到装完的状态，而不是从头再来一遍。

我还会额外做一件事：把安装过程中所有改过的配置文件、执行的命令、填写的参数整理成一份记录。这份记录在后续扩容、迁移、故障恢复时的价值，远超当时花的那半小时。

7. 常见问题与排查实录：那些文档里不会写的东西

这一节是我这些年攒下来的，基本都是官方文档里找不到、但实际会撞上的问题。

7.1 安装阶段的高频报错

报错一：安装程序卡在预检查，提示某个包缺失

这种情况九成是依赖包版本不对。OEL 的包管理会装最新版本，但 Oracle 产品有时只认特定版本区间。解决办法是用rpm -qa | grep 包名看实际版本，对照兼容矩阵，必要时降级或者装兼容包。别直接--nodeps强装，后面会以更诡异的方式报错。

报错二：数据库连接测试失败，但sqlplus能连

这是典型的连接串问题。安装程序用的连接方式和sqlplus不完全一样，检查服务名和 SID 是否混用、监听是否注册了正确的服务。另一可能是密码里有特殊字符被转义了。

报错三：应用部署到一半报“部署目标不可用”

多半是受管节点没起来，或者节点管理器没配好。先去 WebLogic 控制台看服务器状态，再看受管节点的日志。

7.2 运行阶段的典型症状

症状：登录后页面加载极慢，但服务器 CPU 和内存都不高

先看数据库。这种情况常见于某个视图或统计查询缺索引，数据库在闷头做全表扫描。用AWR或者数据库的会话监控，抓一条正在跑的慢 SQL，基本就能定位。

症状：某些用户能看到项目，某些用户看不到

这是权限模型的问题，不是安装问题。P6 的访问权限由项目配置文件、用户组、全局权限共同决定，排查时按“用户 → 组 → 项目配置文件 → 项目”这条链一层层看。

症状：报表页面空白，或者报“无法连接到数据源”

报表组件是独立部署的，它的数据源配置和应用的数据源配置是两回事。检查报表组件的配置文件、数据库连接、以及应用里配置的报表访问地址是否正确。

症状：中文显示成问号或者方块

字符集问题。先查数据库字符集是不是 AL32UTF8，再查应用服务器的区域设置，最后查浏览器端的编码。三层里任何一层不对都会出问题。

7.3 一份能直接照着查的速查表

注意：排查时一定按“从下往上”的顺序，先确认数据库没问题，再看中间件，最后看应用。反过来做，很容易在应用日志里看到一堆由数据库问题引发的次生异常，把自己带偏。

8. 几条踩过坑之后才明白的实在建议

第一，别在同一台机器上装两套 P6。有人为了省资源，想在一个 OEL 实例上装两套环境做测试，结果端口冲突、目录冲突、服务名冲突，折腾的时间远超省下来的机器成本。真要隔离，用两台虚拟机，哪怕配置低一点。

第二，安装介质的完整性先校验。我有一次从内网共享盘拷的安装包，解压到一半报错，重新下载一遍才发现源文件就损坏了。装之前先看校验和，两分钟的事。

第三，把所有密码记在一个地方，并且用同一套命名规则。P6 这套东西涉及的密码太多了：数据库系统账号、几个业务 schema、WebLogic 管理员、应用管理员、内容库、报表组件。装的时候随手记，装完你会发现没有这份清单寸步难行。

第四，日志目录一定要单独规划并定期清理。WebLogic 的日志、数据库的审计日志、应用的调试日志，加起来增长速度非常快。我一般会写个简单的清理脚本挂到定时任务里，保留 30 天，避免某天早上发现磁盘满了导致整个环境挂掉。

第五，升级之前先在生产环境的副本上演练一遍。P6 的版本升级涉及数据库结构变更和应用重新部署，直接在生产上操作风险极高。副本演练能提前暴露兼容性问题，也能让你对升级耗时有个准确预期。

最后分享一个我在实际部署中养成的小习惯：每装完一套环境，我都会写一份“环境说明书”，记录机器配置、端口分配、目录结构、账号职责、启动停止顺序、备份策略。这份东西在交接时特别有用，也能在半年后自己回头看时，快速回忆起当时为什么这么设计。装一套 P6 EPPM 不难，难的是让它在一两年后还能被清楚地维护下去。