企业官网建设流程全解析

简介：Teamcenter 2007详细安装文档面向需要独立部署或维护Teamcenter系统的PLM实施工程师与系统管理员。文档以Oracle 10.0数据库软件安装为切入点，分阶段说明如何通过高级安装模式选择企业版、指定安装路径并仅安装数据库软件，随后指导读者利用Oracle Net Manager建立名为LISTENER的监听程序，并通过lsnrctl命令完成监听启动。在数据库准备环节，文档指出需将Tc2007.1_wnti目录下的数据库脚本复制至Database Configuration Assistant的templates文件夹，再以tceng为全局数据库名、统一口令创建Teamcenter专用数据库。包内为单个doc格式文档共1个文件，大小约3MB，已有214人浏览学习。文档虽针对早期版本，但其中关于数据库层依赖关系和安装顺序的梳理，对理解Teamcenter整体架构仍有实用参考价值，能有效缩短实施前期的环境配置排查时间。

1. Teamcenter 2007 安装：第一步就卡住你的是环境，不是软件

Teamcenter 2007 是很多制造企业 PLM 系统的老底子，网上教程要么只讲单机装个客户端，要么跳过一大堆前置步骤直接说“下一步下一步”。真按那个思路去装，十有八九会在许可服务起不来、数据库连不上、客户端登录报错这三关轮番翻车。我见过不少维护老系统的工程师，接手第一周全在跟安装环境搏斗。这篇我就把 Teamcenter 2007 从零到能登录客户端的完整安装链路拆开讲，重点是那些参数为什么这么设、哪些步骤能跳、哪些坑你一定会踩。适合刚接手老 PLM 系统的新手，也适合准备在测试环境重建一套模拟项目X 的运维老手。

2. 安装前预备：环境检查、账号与目录规划，先做到这三件事

2.1 环境检查清单：操作系统、JDK 与数据库版本，能少走一半弯路

Teamcenter 2007 这代产品对环境要求有个特点：它不挑最新，只挑“对的那一版”。操作系统常见做法是 Windows Server 2008 R2 或 Windows Server 2012，注意用 64 位系统。有人图省事装到 Windows 10 上，也能跑通测试环境，但生产环境我一般不推荐，因为后续补丁、服务重启、权限模型都按 Server 版设计的。

JDK 版本是第一个容易出错的地方。Teamcenter 2007 年代对应的 JDK 通常用 1.6 或 1.7，装 1.8 以上会在启动 Web 服务时遇到类加载异常。检查命令很简单，打开命令行窗口执行：

java -version echo %JAVA_HOME%

安装前先用这两个命令确认当前机器能不能找到 JDK。JAVA_HOME环境变量指向的路径不能带空格，比如C:\Program Files\Java\jdk1.7.0_80这种就不行，常见做法是装在D:\Java\jdk1.7.0_80这样的纯英文短路径。原因在于后续很多启动脚本直接拼接路径，空格会被解析成参数分隔符，服务就起不来。

数据库方面，Teamcenter 2007 常见配套 Oracle 10g 或 11g。选型上我建议 Oracle 11g R2，稳定性和内存管理都比 10g 好，而且网上踩坑资料多。安装 Oracle 时注意字符集要选AL32UTF8，不然后续导入中文字段数据会出现乱码，这是很多人装完才发现的问题，返工成本极高。

2.2 账号与目录规划：安装账号权限、盘符与共享路径，一次规划到位

安装 Teamcenter 2007 不要直接用默认的 Administrator 账号跑服务，常见做法是创建两个专用账号：一个用于安装和日常运维，一个用于服务运行。运维账号加入本地 Administrators 组，服务账号给普通用户权限即可。这么做的好处是后续排查问题能分清是权限不够还是程序异常，不至于什么错都堆在同一个账号上。

目录规划上，我一般这样分：

D:\Teamcenter\ 安装根目录 D:\Teamcenter\config 配置文件目录 D:\Teamcenter\log 日志目录 D:\Teamcenter\temp 临时文件目录 E:\Teamcenter\datavault 数据仓库目录（数据量大单独放一块盘）

数据目录和数据仓库分开，是血泪经验。Teamcenter 2007 的数据仓库会随时间膨胀，和安装目录塞在同一个盘，备份和磁盘空间管理都会很被动。另外所有路径都不要有空格和中文，这个年代的中间件对路径字符集处理不完善，中文路径会导致文件读取失败。

还有一个容易被忽略的配置——hosts 文件。Teamcenter 的许可服务和应用服务器之间通过机器名通信，如果机器名不能被正确解析，服务启动时互相找不到对方。安装前先把机器的完整计算机名记下来，然后编辑 hosts 文件：

192.168.1.100 plm-server 192.168.1.101 plm-db

plm-server是应用服务器机器名，plm-db是数据库服务器机器名。这台机器上跑什么服务，就把它自己的 IP 和机器名对应关系写进去。即使测试环境只在一台机器上装全部组件，也要把本机 IP 映射到机器名，这是最常被跳过的步骤之一。

2.3 防火墙、UAC 与杀毒软件：三个会“静默”杀掉服务的东西

进入安装前，把 Windows 防火墙关了或至少放行几个端口。Teamcenter 2007 涉及的端口很多，许可服务默认 28000，应用服务常见 8080 或 7001，数据库 1521，客户端和服务器通信还有一堆动态端口。逐个去防火墙规则里配太麻烦，且老系统的端口清单不一定找得全，测试环境直接关防火墙最快，生产环境至少放行整段 Teamcenter 用的端口范围。

UAC（用户账户控制）一定要拉到最低。这代中间件在初始化时经常要写系统目录和注册表，UAC 拦截会导致写失败但安装程序不报错，表现为装完服务起不来。杀毒软件更是个隐性杀手，它会扫描正在写入的 jar 包和数据文件，导致安装过程奇慢，甚至把关键组件当病毒隔离。装之前把 Teamcenter 安装目录加入白名单，或者干脆临时退出杀毒软件。

3. 许可服务与数据库层：决定你能不能登录的两块基座

3.1 许可服务安装：License 文件、端口 28000 与环境变量，一个都不能少

Teamcenter 2007 的许可服务是独立于主安装程序的一个组件。常见做法是先装许可服务，再装应用服务，顺序反了容易在应用服务检测许可时超时。许可服务的安装本身很简单，麻烦在 License 文件。

License 文件一般由厂商提供，里面绑定机器的主机名和 MAC 地址。很多人装完发现许可服务起不来，第一反应是服务程序有问题，其实八成是 License 文件和机器信息不匹配。安装前确认三件事：

• 机器主机名和 License 文件里写的是否一致，注意大小写也敏感
• 网卡的 MAC 地址是否绑定正确，多网卡机器要确认用的是哪个网卡
• License 文件保存为文本格式，不要用带 BOM 头的 UTF-8 编码，这会导致解析失败

许可服务装完后，设置环境变量指向许可文件路径：

set LM_LICENSE_FILE=27000@plm-server

这里 27000 是许可服务端口和主机名。常见做法是用 vender daemon 方式运行，端口号要跟安装时填写的一致。验证许可服务是否正常，用命令窗口进入许可工具的安装目录，执行：

lmutil lmstat -a -c 27000@plm-server

看到license server UP的提示就说明服务没问题。这条命令的输出还能看到哪些功能模块被授权了。如果显示cannot connect to license server，先检查端口是不是被防火墙挡了，再确认服务有没有真的起来，最后才怀疑 License 文件本身。排查顺序很重要，很多人一上来就重新生成 License 文件，折腾半天发现只是服务没启动。

3.2 Oracle 数据库准备：实例、表空间与账号，按这个顺序执行不会乱

数据库层是 Teamcenter 2007 安装里最容易出问题的环节，因为它要求数据库实例、表空间、账号三者全部就绪后才能跑初始化脚本。先创建实例，再建表空间，然后建账号并授权，顺序不要反。

用 SQL Plus 以 SYS 账号登录后，第一步创建表空间。Teamcenter 的数据分几类，常见的做法是分配数据表空间和索引表空间：

CREATE TABLESPACE TC_DATA DATAFILE 'D:\ORACLE\ORADATA\PLMDB\TC_DATA01.DBF' SIZE 10G AUTOEXTEND ON NEXT 500M MAXSIZE UNLIMITED; CREATE TABLESPACE TC_IDX DATAFILE 'D:\ORACLE\ORADATA\PLMDB\TC_IDX01.DBF' SIZE 5G AUTOEXTEND ON NEXT 200M MAXSIZE UNLIMITED;

表空间大小按业务量预估，测试环境 10G 起步够用，生产环境建议 50G 以上。AUTOEXTEND ON是为了避免数据库满了之后服务直接报错，NEXT指定每次自动增长的大小，不要设太小，否则频繁扩展会影响性能。

接着创建 Teamcenter 的系统账号，常见用infodba作为主账号，密码注意符合 Oracle 11g 的密码复杂度要求，否则建号失败。再创建一个普通业务账号，用于日常运维连接：

CREATE USER infodba IDENTIFIED BY "Tc2007#Admin" DEFAULT TABLESPACE TC_DATA TEMPORARY TABLESPACE TEMP QUOTA UNLIMITED ON TC_DATA; GRANT CONNECT, RESOURCE, DBA TO infodba;

这里DBA权限是 Teamcenter 2007 初始化脚本的要求，它要建大量表和存储过程，普通权限不够。生产环境有人为了安全不给 DBA 权限，然后初始化脚本跑一半报权限不足，反而更麻烦。初始化完成后再评估收紧权限是更稳妥的策略。

TEMP 临时表空间建议单独设一个比较大的，初始不小于 2G。Teamcenter 初始化时会有大批量数据排序操作，临时表空间太小会直接报 ORA-01652 错误。

3.3 数据库初始化脚本：isql 工具、批处理执行与日志分析

数据库账号建好后，进入 Teamcenter 安装介质的site目录，找到数据库初始化脚本。Teamcenter 2007 提供了批处理脚本，常见是tc_db_config.bat之类的文件，运行前要修改脚本里的数据库 SID、账号、密码参数。

先测试数据库连接是否通畅，用 Teamcenter 自带的 isql 工具执行一条简单 SQL：

isql -U infodba -P "Tc2007#Admin" -S PLMDB

-S指定 Oracle 实例名。连接成功后会进入 SQL 提示符，执行一句select 1 from dual;能返回结果就说明 ODBC 配置没问题。如果连不上，检查 Oracle 监听器状态和数据库服务名，用lsnrctl status命令确认监听端口 1521 是否正常。

连接没问题后，运行初始化脚本开始建表。这个过程耗时较长，测试环境一般 20-40 分钟，中途不要断开连接或关闭窗口。脚本执行的输出会记在日志文件里，位置通常在site\log目录下。判断成功与否不能只看窗口没报错，要检查日志尾部有没有consistent或successfully之类明显标记：

tail -50 install.log

常见的失败原因集中在账号权限不足、表空间路径不存在、Oracle 字符集不对三类。日志里如果出现ORA-00959，说明表空间名字对不上，回去看建表空间步骤；出现ORA-01950说明账号配额不够，补QUOTA UNLIMITED再跑。这里有个试错技巧：脚本初始化失败后，不用删库重来，把建好的表空间保留，只删除账号重建，再执行脚本即可。前提是失败在很早期，表还没建多少。

4. 应用服务与客户端：把“能连数据库”变成“能登录进去”

4.1 应用服务器配置：站点 ID、线程池、JVM 内存，三个参数决定稳定性

数据库层就绪后，开始正式安装 Teamcenter 应用服务。安装向导里会有几个关键配置项，填错了后面客户端登录时才会暴露问题。

站点 ID 是 Teamcenter 内部分辨环境用的唯一标识。单环境部署填 1 就行，如果同一个数据库里要跑多套环境，站点 ID 要区分。这个参数后期改起来麻烦，安装时就确定好，别等系统跑起来再动。

线程池大小默认值一般不够用。Teamcenter 2007 的线程池配置在应用服务的配置文件中，常见路径是installed\configuration\portal\portal.properties或类似文件。核心参数是最大线程数和 JVM 启动内存：

tc.maxThreads=200 tc.minSpareThreads=40 java.additional=-Xms1024m -Xmx2048m

tc.maxThreads控制并发会话数上限，测试环境设 200 够用，生产环境按在线用户数估算，一般 500 起步。-Xms和-Xmx是 JVM 初始和最大堆内存，这代中间件内存管理不激进，-Xmx设 2048m 是稳妥值，设太大反而会因为垃圾回收停顿影响响应。如果真的需要更大内存，优先扩容物理内存而不是只调这个值。

启动顺序也讲究，常见顺序是：先数据库、再许可服务、再应用服务。有人图省事一次性启动所有服务，结果应用服务先把数据库连接池建满，再启动数据库时被拒，然后连锁报错。命令行启动应用服务后，观察控制台日志：

D:\Teamcenter\installed\bin\startup.bat tail -100 D:\Teamcenter\log\server.log

日志里看到Application server started successfully才算完成。服务启动过程一般 3-5 分钟，如果你觉得启动太快，反而不正常，大概率某个组件没加载齐。

4.2 客户端连接参数：服务器地址、端口与服务名称，登录前的最后一道门槛

客户端安装相对简单，难点在连接参数的配置。Teamcenter 2007 的胖客户端安装时会要求填服务器地址和端口。很多人这里填了机器 IP，结果装上后连不上，因为服务端配置里绑定的是机器名，两边不一致。

推荐的做法是填机器名而不是 IP，前提是客户端机器的 hosts 文件也加了对应映射。如果客户端分布在多台机器上，每台都要维护 hosts，这就是前面为什么强调服务端用机器名的原因——用 IP 的话，服务端和客户端的绑定关系一旦变化，全部客户端都要改。

客户端连接属性维护在一个配置文件中，常见在客户端安装目录的portal\registry\site_\xxx.properties。手动核对三个关键项：

tccs.host=plm-server tccs.http.port=8080 tc.server.name=plm-server

tccs.host和tc.server.name指向应用服务器，tccs.http.port是应用服务 HTTP 端口。如果客户端连接时报 “cannot find server”，用 ping 命令先测网络通不通，再看 TCP 端口是否监听。Windows 下用：

netstat -ano | findstr 8080

端口有监听的，问题在配置文件；没有监听，回去查应用服务启动状态。这里有个玄学现象：偶尔服务起来后端口监听有延迟，等两三分钟再连就好了，不用一失败就重启服务。

5. 避坑与排查清单：Teamcenter 2007 安装中反复出现的五个问题

5.1 Oracle 密码策略导致连接失败，初始化成功后服务一重启就连不上

现象：数据库初始化脚本跑完，应用服务也起来了，但过几天重启服务后，客户端连接报 ORA-28001（密码已过期）。

原因：Oracle 11g 默认启用了密码生命周期策略，默认 180 天密码过期。Teamcenter 2007 的服务配置中存储的密码不会跟随 Oracle 策略自动更新，服务无法感知密码已过期。

解决：初始化完成后立刻修改 Oracle 密码策略，把PASSWORD_LIFE_TIME设为无限。常见操作：

ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED; ALTER USER infodba IDENTIFIED BY "Tc2007#Admin";

改完后重启应用服务验证一次，避免下次重启再栽跟头。

5.2 hosts 文件没配机器名，许可服务自己起来了但应用服务找不到它

现象：许可服务用 lmutil 查看状态是 UP，但安装应用服务时检测许可一直失败，或启动应用服务报 license 相关的错误。

原因：应用服务启动时按机器名解析许可服务器地址，hosts 文件里没有对应映射，解析走 DNS 失败，超时后判定无许可。

解决：把应用服务器和许可服务器的机器名映射都写进 hosts，注意要写完整计算机名，不是只写主机名前段。写完后用nslookup plm-server验证能解析出正确 IP。

5.3 重新安装时残留胎记：服务起不来，日志里全是端口占用

现象：卸载再重装后，应用服务启动报端口被占用，或者注册的服务名称冲突。

原因：Teamcenter 2007 的卸载不清理干净。NT 服务注册表项、环境变量、配置文件残留，重装时检测到已存在组件，跳过部分安装步骤，配置却是新旧混合。

解决：重装前手动做三件事。第一，在服务管理器里停掉并删除旧的 Teamcenter 相关服务；第二，清理环境变量TC_ROOT、TC_DATA等路径残留；第三，把安装目录整个改名而不是直接覆盖装。这套流程能避免九成重装翻车。

5.4 客户端登录报“JDK 版本不兼容”，但服务端明明没有这个问题

现象：服务端一切正常，客户端装好后双击登录器，直接弹 JVM 相关的错误框，闪退。

原因：客户端自带的 Java 运行时老化和系统预装 JDK 冲突。客户端优先去找系统 JAVA_HOME，结果找到个版本更高的 JDK，加载不了老客户端类。

解决：在客户端启动脚本里强制指定使用自带 JRE 路径，不要跟随系统环境变量。编辑客户端安装目录下的启动脚本：

set JAVA_HOME=C:\TeamcenterClient\jre

然后在命令行手动启动一次，确认能正常弹登录窗口后再回到桌面图标。

5.5 服务运行几天后自动停止，日志里没有任何异常

现象：应用服务跑了两三天后自动停了，看一下日志文件，最后一条输出都是正常信息，没有报错。

原因：内存泄漏。Teamcenter 2007 这代的内存管理不完善，长时间运行的 JVM 慢慢膨胀到峰值后触发崩溃，日志往往来不及写错误信息。

解决：在启动脚本里加上 JVM 参数，让内存在达到阈值时自动重启服务进程，而不是干等崩溃：

java.additional=-Xmx2048m -XX:MaxMetaspaceSize=256m

同时配置 Windows 服务失败后的自动重启动作：服务属性里“恢复”标签页，把第一次失败、第二次失败都设为“重新启动服务”。这是老系统运维的常规动作。

6. 初始化业务模板：把空壳系统变成能用的 PLM 环境，验证清单别跳过

6.1 业务模板与基础数据：导入模板、建用户、配权限，三十分钟内完成

Teamcenter 2007 装完并登录后，系统里其实是空的——没有数据类型、没有流程模板、没有用户。别急着让业务人员来试，先做三件事。

第一，导入业务模板。Teamcenter 2007 安装介质里自带一批基础模板，常见在install\configuration目录，通过管理端导入工具加载。导入后检查“已部署的业务对象”列表是否完整，重点看文档、物料（Item）、变更单三类对象有没有生成。

第二，创建测试用户。用infodba登录后创建两个角色：一个配置管理员，一个普通用户。配置管理员权限要充分，否则后面配工作流时会到处报没权限。

第三，验证权限模型。给普通用户配好操作权限，用普通用户登录试试创建文档、发起变更流程。这个动作看起来多余，但能提前暴露权限继承的问题，免得业务部门上线当天才发现连文件都传不了。

6.2 全链路验证清单：按这个顺序测完，基本可以交付使用

我每次装完 Teamcenter 2007，都按下面这份清单跑一遍，全部通过才敢说系统可用：

• 数据库层：用isql重新连接，执行一次简单查询，确认数据库服务重启后仍能连通
• 许可层：运行lmutil lmstat -a，确认全部需要的功能模块都在授权列表中
• 应用层：浏览器访问 Web 客户端登录页（端口 8080），确认页面能正常打开
• 客户端层：用配置管理员账号登录胖客户端，创建一条测试数据，再把它查出来
• 文件读写：在客户端上传一个文档，确认数据仓库目录里生成了物理文件，再删掉它回收存储

这套验证清单的实际价值不只是证明“装完了”，更重要的是给维护期留一份基线。以后系统出问题，先从这份清单倒回去查，哪个环节不对，故障范围就圈定了。我有一次被叫去处理系统无法上传文件的故障，把所有服务查了个遍都没发现问题，最后顺着这条链排查，才发现是数据仓库所在的 E 盘满了。从那以后我养成一个习惯：安装文档里永远留一份磁盘空间基线记录。希望这套从环境准备到业务模板初始化的思路，能帮你在 Teamcenter 2007 这条路上少些反复，多些确定。

本文还有配套的精品资源，点击获取