1. 先把这套环境说清楚OEL 上跑 P6 EPPM 到底在装什么P6 EPPM 在 OEL 上的安装本质是把三块相互独立又强耦合的东西拼到一起一个 Oracle 数据库撑着数据一套 Java 中间件撑着应用再加一份层层叠叠的应用介质把业务模块布上去。很多人第一次装的时候脑子里只有一个模糊的印象——“装个软件”结果在前面aming几十分钟、到部署环节才发现前面数据库建库时的字符集选错、表空间没规划好、系统内核参数没调后面全得推倒重来。我经手过几套从零搭建的项目管理平台环境最惨的一次是数据库建完发现字符集不是 AL32UTF8中文字段在 P6 Web 里显示成问号最后只能删库重来——那一次让我彻底改掉了“先装起来再说”的习惯。P6 EPPM 是工程行业里做进度计划、资源与成本管理的核心平台它的使用场景非常具体施工总承包单位的计划部门要把几千上万条活动编制成网络计划项目部要按周更新实际进度管理层要看里程碑偏差商务口要拉资源曲线和费用曲线。这套系统天生就是“重数据库、重报表、多人并发”的形态不是那种装个单机版就能用的轻量工具。所以它落在 OEL 上最合理的形态是一台数据库服务器加一台应用服务器规模再小也别把两者压在同一个操作系统实例里——这不是洁癖是内存和 IO 抢得太厉害。OELOracle Linux之所以成为这类环境的首选道理很朴素同一家厂商的数据库、中间件、操作系统官方兼容性矩阵里写得明明白白遇到问题翻文档不用在三家社区之间来回猜。而且 OEL 的内核和包管理跟主流企业级发行版同源运维同事上手成本低yum/dnf装依赖、配本地源都很顺手。相比之下用非企业级发行版去跑 Oracle 数据库官方支持层面会比较尴尬出问题只能自己扛。Prisma不是。P6 EPPM 的核心组件可以这样拆Oracle Database存放全部业务数据P6 会在里面建若干个职责分离的 schema分别管应用元数据、项目私有数据、公共数据。Oracle WebLogic ServerP6 的应用容器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 内存数据库吃掉 8GWebLogic 起两个受管节点又各要 4G系统剩下不到 2G跑起来之后页面点一下要等十几秒还以为是安装出错其实是内存被榨干了。2.1 内存与 CPU 的分配逻辑我的经验算法是这样的先定并发用户数再倒推。P6 Web 的并发用户并不是一人一个线程但每个活跃会话在 JVM 里都会占一块内存加上连接池、缓存一个中等负载的受管节点给 4G 堆是比较稳妥的起点。数据库侧SGA 一般按物理内存的 40%~50% 给但前提是应用不跟它抢。规模并发用户数据库服务器应用服务器说明小型单项目部试点5~204 核 / 16G4 核 / 16G数据库与应用分离最低配置中型多项目并行20~808 核 / 32G8 核 / 32G应用侧可起两个受管节点较大规模80~20016 核 / 64G16 核 / 64G需考虑报表单独拆分节点上表是经验区间不是官方硬指标。真实项目里我一般会在中型配置上再留 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 libaiooracle-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.*/SELINUXpermissive/ /etc/selinux/config firewall-cmd --permanent --add-port1521/tcp firewall-cmd --permanent --add-port7001/tcp firewall-cmd --permanent --add-port8000/tcp firewall-cmd --reload4. 数据库层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 上线前我一定会检查这几个参数参数建议值原因processes500 以上P6 连接池加报表并发默认 150 容易撞上限open_cursors1000P6 的复杂查询游标用量大session_cached_cursors100提升重复查询效率undo_retention10800大批量计划运算时避免快照过旧optimizer_features_enable按版本固定避免升级后执行计划突变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 管理端口设成 7001P6 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:MetaspaceSize512m -XX:MaxMetaspaceSize1024m6. 上线前的验证与调优按层次往下打我从不相信“装完能打开首页就算成功”。P6 这种多组件系统必须按层次逐级验证每一层都确认通了再往下走否则出问题时根本不知道该怀疑谁。6.1 逐层验证的顺序与手段我的验证顺序是数据库监听 → 数据库连接 → schema 可用性 → WebLogic 管理服务器 → 受管节点 → P6 应用首页 → 登录 → 创建测试项目 → 报表输出 → 附件上传。每一步都有明确的判断标准不是“看着没报错”就算过。层次验证手段通过标准数据库监听lsnrctl status服务已注册状态 READY数据库连接sqlplus登录业务 schema能查到 P6 的系统表WebLogic 管理访问管理控制台能登录服务器状态 RUNNING应用首页浏览器访问 P6 地址登录页正常渲染无 500 错误业务功能新建项目、加活动、保存数据落库刷新后还在报表打开任一标准报表有数据输出不是空白页附件上传一个小文件能上传能下载这个表格我每次实施都带着逐项打勾。有一次在一个环境上前面六项全过最后附件上传失败查下来是内容库的目录权限问题——如果只验证到“能登录”这个问题会等到用户第一次传文档才暴露。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 一份能直接照着查的速查表现象优先排查方向常用手段装到一半报错退出安装日志、依赖包版本翻安装目录下的日志文件数据库连不上监听、服务名、密码转义lsnrctl status、tnsping应用起不来受管节点日志、端口占用ss -lntp、看ManagedServer.log页面 500 错误应用日志中的异常栈抓第一个 Caused by保存操作超时数据库锁、连接池耗尽查v$session、连接池监控定时任务不执行作业调度组件状态查调度服务日志与时间配置附件传不上去内容库目录权限与容量检查目录属主、磁盘剩余注意排查时一定按“从下往上”的顺序先确认数据库没问题再看中间件最后看应用。反过来做很容易在应用日志里看到一堆由数据库问题引发的次生异常把自己带偏。8. 几条踩过坑之后才明白的实在建议第一别在同一台机器上装两套 P6。有人为了省资源想在一个 OEL 实例上装两套环境做测试结果端口冲突、目录冲突、服务名冲突折腾的时间远超省下来的机器成本。真要隔离用两台虚拟机哪怕配置低一点。第二安装介质的完整性先校验。我有一次从内网共享盘拷的安装包解压到一半报错重新下载一遍才发现源文件就损坏了。装之前先看校验和两分钟的事。第三把所有密码记在一个地方并且用同一套命名规则。P6 这套东西涉及的密码太多了数据库系统账号、几个业务 schema、WebLogic 管理员、应用管理员、内容库、报表组件。装的时候随手记装完你会发现没有这份清单寸步难行。第四日志目录一定要单独规划并定期清理。WebLogic 的日志、数据库的审计日志、应用的调试日志加起来增长速度非常快。我一般会写个简单的清理脚本挂到定时任务里保留 30 天避免某天早上发现磁盘满了导致整个环境挂掉。第五升级之前先在生产环境的副本上演练一遍。P6 的版本升级涉及数据库结构变更和应用重新部署直接在生产上操作风险极高。副本演练能提前暴露兼容性问题也能让你对升级耗时有个准确预期。最后分享一个我在实际部署中养成的小习惯每装完一套环境我都会写一份“环境说明书”记录机器配置、端口分配、目录结构、账号职责、启动停止顺序、备份策略。这份东西在交接时特别有用也能在半年后自己回头看时快速回忆起当时为什么这么设计。装一套 P6 EPPM 不难难的是让它在一两年后还能被清楚地维护下去。