性能是衡量软件系统的一个重要部分，可能引起性能低下的原因很多，如CPU/内存/网络资源不足，硬盘读写速度慢，数据库配置不合理，数据库对象规划或存储方式不合理，模块设计对性能考虑不足等。
1 数据库配置
1.1 SGA配置
Oracle服务器从10g开始，提供了自动共享内存管理，可以免去很多在9i上共享内存调整的麻烦。
如果你使用的是10g或以上版本，建议设置好SGA最大大小后，采用“自动共享内存管理”服务器会自动为你根据应用的情况分配各项参数的数值。
1.2. PGA配置
PGA主要用于缓存进程数据和一些控制信息，无论有多少个进程访问Oracle服务器，SGA是提供共享的内存区域，而PGA则为每个进程分别提供内存区域。因此，当访问Oracle的进程较多的情况下，PGA的内存设置也是需要注意的问题。此外，PGA空间大小对于提高缓存命中率有较大帮助。在设置其大小时，可以根据Oracle服务器对缓存命中率统计的数值进行调整，设置的大小最好能使命中率保持在95%以上。
1.3. 初始化参数设置
以下列出最为常用的数据库服务器初始化参数及其设置，注意，在设置时应使其应用在当前有效的启动文件中（spfile 或pfile），如果只是修改了当前内存中的参数，那么下次启动又会使用到修改前的那些参数取值。
a)log_checkpoint_timeout：两个检查点之间最大的时间间隔，默认1800秒。对于并发访问用户较多情况下，因为事务处理较为频繁，很容易产生数据文件与日志文件对磁盘资源的争用，因此可以适当修改该值（5000-30000）
b) open_cursors：每次数据库会话最大能同时打开的游标个数，默认300。一般不需要调整，当应用过程中出现类似“游标超出最大数”的异常信息时，可以将其适当调高，如500-1000内。出现这种情况，可能是某些代码实现过程中，没有在合适的时机关闭使用过的游标，也可能是某些应用逻辑较为复杂，确实会出现峰值超出300的情况
c) sessions：数据库服务器允许并存的会话最大值，包括用户会话和系统会话。如果使
用单一的PLM服务器连接该库，但并发用户数很大，或者同时有多个PLM服务器连接该库，或其他应用需要连接库，那么比较容易导致session 到达最大值，最终产生的现象是：数据库服务器状态良好（CPU/内存使用正常），但使用pl/sql或其他工具直接访问数据库时无法连接，或很长时间才能连接上；一旦将PLM服务器
或其他连接数据库的工具退出或关闭，数据库很快恢复正常。如果是这样的现象，一般可以通过设置sessions的取值，将其适当地设置得大一些，但该值取决于软硬件条件，不能设置过大
4) shared_pool_reserved_size：共享池保留区大小，用户缓存预编译的sql 程序、存储过程等，一般情况下设置为共享池大小的5%-10%。在Oracle10g自动内存管理模式下，不需要手工调整
5) sort_area_size：内存排序工作区大小，对于提高排序运算效率很有帮助，如果设置太小，而排序运算很多时，则会转为使用临时表空间，利用磁盘空间排序性能会明显下降。一般情况下设置为PGA大小的5%-10%
1.4. 举例
1.4.1. 2 core CPU*2+4GB+RAID5+Windows2003 Server+Oracle9i x86+PLM Application/File Server
SGA最大：1.5GB
Java池：8MB
大型池：32MB
共享池：300MB
高速缓存：1.1GB
PGA：1GB
log_checkpoint_timeout：20000
open_cursors：500
shared_pool_reserved_size：20000000
sort_area_size：70000000
1.4.2. 4 core CPU*2+16GB+RAID10+Windows 2008 Server+Oracle10g x64
SGA最大：8GB，自动内存管理
PGA：2GB
log_checkpoint_timeout：10000
open_cursors：500
sort_area_size：120000000
1.5. 注意事项
1. 尽量避免如同一数据库服务器为多个应用服务
2. 当物理内存在4G或更少的情况下，应尽量避免在服务器上运行其他应用程序或服务（如Web系统）
3. 如可能，尽量不在数据库服务上运行杀毒软件或其他防火墙软件，减少对网络/内存/磁盘资源的占用，尽量不要为数据库服务器开放共享目录作为软件服务器使用，尽可能保持其独立性和隔离性
4. 硬件配置和性能是软件系统高效运行的基本保证，如果没有了这个前提，很难通过软件本身的配置或优化进行有效的提升
2. 常见性能原因和对策
我们发现，有时服务器的CPU和内存使用不饱和，甚至利用率很低，但一些正常操作就是很慢；有时系统速度则时快时慢；还有些情况下则是随着时间推移越来越慢。出现这些现象的原因有多种，比如第一种情况一般说明瓶颈在磁盘读写上，第二种情况则与并发用户数或网络资源有关，第三种情况则可能是因为对服务器缺乏有效的日常维护。无论出现怎样的性能问题，应首先把握整体情况，并针对现象进行分析，必要时做出一些调整，再进行观察。找出原因是最重要的，利用一些性能监控工具（如Oracle自带的工具）是成功找到原因的一种有效途径。
根据目前PLM系统在企业运行的情况来看，出现性能问题一般有以下几种原因：
a) 硬件配置低（如内存较小，CPU较慢，磁盘读写速度低，网络带宽窄）
对策：通过对硬件资源的了解，确认为该种情况后，通过硬件升级来提高。
b)数据库服务缺乏基本有效的参数配置
对策：通过查看Oracle服务配置参数，确认为参数未设置或需要优化后，根据硬件
情况对其进行设置，可参见上一章。
c) 服务器缺乏必要的日常维护，如虚存文件盘可用空间不足，数据文件盘碎片太多等待
对策：检查服务器各逻辑盘（尤其是Oracle数据存储所在盘）是否有足够可用空间，以及磁盘碎片情况，并根据情况进行调整和优化。磁盘碎片整理是一种简单有效的优化手段，必须将其作为数据库管理员日常工作来执行，定期整理非常必要。注意：整理前应将Oracle所有服务停止。
d) 数据库缺乏必要的日常维护，如没有定期进行表和索引的分析
对策：数据库管理了大量表和索引，在应用过程中，这些表或索引的数据也会像硬盘文件一样变得不连续，甚至于一条记录都分散在不同数据文件的不同数据块中，数据记录越离散，从中对其进行定位的效率就越低。因此，定期对表和索引进行整理是非常必要的。
方法1：系统管理员定期对数据库进行表分析和索引重建工作，或者在库中创建一个Job，调用PLM提供的存储过程包来自动执行以上工作。plm_optimize.stattable(‘数据库用户名’);
plm_optimize.rebuildindexes;
方法2：将整个数据库重新导出/导入一次，是使数据变得连续最有效的方式，单从性能角度来说，比方法1更优。
e)软件模块的性能设计不足
对策：需要充分估计数据量增长趋势，并结合并发用户数情况，对数据库层设计进行改进
f) 其他（如：缺乏有效的索引，导致查询性能低）
对策：需针对具体情况进行监测和分析，给出解决方案。
