管理Oracle Session是後臺DBMS採用Oracle的信息管理系統的一個重要工作。如果管理不當，會對系統的性能和運行的穩定性產生非常大的影響。Oracle Session是非常寶貴的資源，其數量通常都是有一個固定的設定值，對於Oracle 10g Enterprise Edition來說，如果不修改初始化參數，那麼默認最大的Session數爲170個，在後期系統管理員可以根據實際的需要來修改這個數值。因此係統必須非常小心的管理這些Session。本文主要就多層分佈式系統中Oracle Session的管理提供解決方案。下圖是本文所述的多層分佈式管理系統的模型圖，層與層之間的調用關係如圖所示。
對於使用.NET Framework作爲開發平臺的系統來說，如果是Web Application或者Smart Client Application，在中間件層，應用程序服務器多采用IIS，業務邏輯組件和數據訪問組件通常寄宿在IIS進程中運行。如果採用此種部署方案，那麼影響Oracle Session的主要是兩種因素：
1）IIS進程數；
2）連接池的設置。
一、連接池對Oracle Session的影響
在現代的軟件設計中，爲了提高系統的性能，在數據訪問層通常會採用連接池來改善數據庫連接的效率來改善系統的性能，很多人可能不知道連接池的配置對Oracle Session的產生有着至關重要的影響。連接池對Oracle Session影響主要有兩個因素：
1）對於ADO.NET來說，對於不同的連接字符串會產生不同的連接池。
2）min pool size的值。
對於使用了連接池的數據訪問層來說，Oracle Session的產生機制爲：minsessions=（連接池數）X（min pool size）。值得注意的是每次產生新的Oracle Session是在不同AppDomain邊界產生的時候發生的，也就是說不同的進程每執行一次就會產生minsessions個oracle Session，直到這個進程結束纔會釋放這些session。
二、IIS進程數對Oracle Session的影響
在IIS6.0中，採用了新的進程隔離模式來響應用戶的請求，管理員可以設置多個進程來滿足實際的需要。IIS進程管理器（實際上是inetinfo.exe）負責調度這些進程。在IIS管理器中，我們可以這樣來增加IIS進程數。
在Web 園中，我們可以設置最大工作進程數。設置完以後，打開任務管理器，如果有請求發過來，我們可以看到多了很多W3wp.exe。
上文說到Oracle Session是在不同的AppDomain邊界產生的時候發生的，因此不同的請求發送到IIS以後，每一個IIS進程使Oracle產生min pool size個Sessions。按照這個推算，那麼實際產生的會話數爲：
Sessions = （IIS process number） X （min pool size）。
從上文的分析中我們可以得出，對於Oracle來說，安全的Sessions數應該爲Sessions = （IIS process number） X （min pool size）X（連接池數）。假定連接池數爲1，連接池min pool size爲10，iis進程數爲30，那麼安全的Oracle Sessions的數量應該爲300。如果不按照這個數量進行設置，那麼系統運行的過程中IIS會經常報告一些莫名奇妙的錯誤，如認證失敗。很多人可能會認爲IIS已經Crash了，實際上是由於Session的數量超過了Oracle允許的數量。
當然我們還必須將由於程序異常處理不當等造成的壞死的Session的可能數量計算在內。爲了保證系統的運行問題，應該在上文所說的計算方法上加一個保險值，如350。