性能是衡量軟件系統的一個重要部分，可能引起性能低下的原因很多，如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) 其他（如：缺乏有效的索引，導致查詢性能低）
對策：需針對具體情況進行監測和分析，給出解決方案。