本節書摘來自華章計算機《oracle資料庫性能優化方法論和最佳實踐》一書中的第3章，第3.2節，作者：柳遵梁 潘敏君 應以峰著，更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視
2.6節已經介紹過資料庫登入流程的分解如下：
step 1：用戶端登入請求。
step 2：listener處理和響應。
step 3：服務程序派生。
step 4：程序初始化和session初始化。
step 5：使用者驗證和權限判斷。
step 6：session審計。
step 7：登入觸發器。
step 8：響應用戶端。
對于資料庫登入流程來說，業務需求表述的輸入請求和技術層面的輸入請求完全一緻。每次資料庫登入都對應着一次用戶端登入請求，輸出響應時間自然就是資料庫登入流程的響應時間了。
3.2.1 資料庫登入流程的輸入吞吐量和輸出響應名額
1.?輸入/輸出名額
在實際可測量名額計算中，本書均以某個特定時間段作為測量的時間範疇。
測量範圍基準。
begin time：開始時間。
end time：結束時間。
timeinterval：時間範圍，機關為秒。
輸入吞吐量名額。
logons：資料庫登入次數。
logons per second：每秒資料庫登入次數。
logons per second = logons / timeinterval。
輸出響應名額。
logon response time：資料庫登入響應時間。
logon response time per logon：每次資料庫登入的平均響應時間。
logon response time per logon = logon response time / logons
從資料庫登入流程的輸入請求來看，資料庫登入次數是一個比較合适的輸入吞吐量壓力名額，不管資料庫登入是來自于用戶端、database link、j2ee中間件還是其他中間件，不管是來自于odbc、jdbc還是oci的連接配接，其處理過程都沒有本質的差異。
2.?logons輸入吞吐量名額的測量
以下主要考慮如何獲得logons和logons per second統計名額。
（1）系統啟動以來的logons輸入名額
oracle資料庫的性能名額測量體系已經比較完備，對于logons，已經分别在15s、60s及基于awr自定義快照和啟動以來的總計等不同角度進行統計。
系統性能視圖v$sysstat包含以下兩個統計名額。
1）logons cumulative：自執行個體啟動後的總登入次數，該統計包含成功驗證登入和失敗驗證登入。
2）logons current：目前連接配接到執行個體的sessions。
我們可以用以下公式來計算logons輸入名額。
logons = endsnap. logons cumulative – startsnap. logons cumulative
logons cumulative計算logons增量的代碼如圖3-1所示。
（2）v$sysstat在awr中的展現
oracle awr計算了v$sysstat，存儲在wrh$_sysstat表格中。awr依據快照時間間隔定義可以得到任意的時間範圍資料，考慮到awr的成本和準确性，awr一般會把時間間隔設定在10min以上，圖3-2即為從awr表格中計算logons cumulative增量的代碼。
（3）最近60s和最近15s的近實時的統計名額
oracle在系統性能視圖中提供了接近實時的名額統計。
v$metric：最近15s和60s的名額統計資訊。
v$metric_history：最近1h的60s統計和最近3min的15s統計。
v$sysmetric：v$metric的子集合，僅統計15s和60s系統級别的資訊。
v$sysmetric_history：v$metric_history的子集合，僅統計15s和60s系統級别的資訊。
v$metric視圖的資訊如圖3-3所示。
v$metric _history視圖的資訊如圖3-4所示。
（4）最近1小時的名額統計
v$sysmetric_summary在最近1小時範圍内對v$sysmetric進行了歸類操作，計算最大值、最小值和平均值等資訊，如圖3-5所示。
awr也對v$sysmetric和v$sysmetric_summary進行了處理，包括wrh$_sysmetric和wrh$_sysmetric_summary表格，如圖3-6所示。
3.?輸出響應名額的測量
以下主要讨論如何建立測量名額logon response time和logon response time per logon。通過實際的client、listener和server系統跟蹤，可以大緻明确資料庫登入在各個階段的輸出時間響應名額的比例關系。
下面來看一個具體的資料庫登入跟蹤狀況。
user程序開始工作的時間為：07:15:16:901。
user程序結束工作的時間為：07:15:17:234。
listener程序開始工作的時間為：07:15:16:923。
listener程序結束工作的時間為：07:15:17:072。
server程序開始工作的時間為：07:15:17:038。
server程序結束工作的時間為：07:15:17:232。
user程序的持續時間為：333ms，也是整個資料庫登入流程的持續時間。
listener程序的持續時間為：149ms。
server程序的持續時間為：194ms。
從user程序或者使用者的角度而言，大緻工作流程的時間分布如下。
step 1：讀取配置檔案，為發起listener連接配接申請做好預處理。
開始時間：07:15:16:901；
結束時間：07:15:16:923；
持續時間：22ms。
step 2：ping listener。
開始時間：07:15:16:923；
結束時間：07:15:16:946；
持續時間：23ms。
開始時間：07:15:16:949；
結束時間：07:15:17:066；
持續時間：117ms（注意在服務程序派生期間，使用者程序處于等待狀态）。
step 4：完成client和server的握手。
開始時間：07:15:17:068；
結束時間：07:15:17:079；
持續時間：11ms。
step 5：完成鍊路通信準備和互相注冊。
開始時間：07:15:17:080；
結束時間：07:15:17:120；
持續時間：40ms。
step 6：完成使用者名發送和檢驗。
開始時間：07:15:17:123；
結束時間：07:15:17:136；
持續時間：13ms。
step 7：完成密碼傳遞、驗證和session資訊發送。
開始時間：07:15:17:136；
結束時間：07:15:17:160；
持續時間：24ms。
step 8：完成權限判斷和session初始化工作。
開始時間：07:15:17:164；
結束時間：07:15:17:234；
持續時間：70ms。
從上述描述可以看出，影響資料庫登入流程效率主要來自以下幾個方面。
網絡來回開銷，在client和server之間需要極為頻繁的網絡溝通。至少18個資料通信來回和2個握手來回。
服務程序派生和重新握手達到130ms，占整個時間的40%左右，有絕對的影響。
使用者權限判斷和session初始化也達到70ms，達到20%左右。
使用者程序預處理在本地配置檔案龐大的時候可能會遇到障礙。
（1）v$sys_time_model、v$sess_time_model視圖和響應時間統計
v$sys_time_model作為oracle響應時間分析最為核心的視圖，提供了目前可以提供的各種時間響應和時間分解的統計值。從v$sys_time_model視圖中顯然無法區分出消耗的時間是消耗于資料庫登入還是資料庫通路，也就是說，無法從v$sys_time_model視圖中擷取logon response time，如圖3-7所示。
v$sess_time_model視圖記錄了每個session的服務時間響應，雖然與v$sys_time_model一樣，随着時間的推移，其服務時間響應将與資料庫通路處理合并而無法區分，但可以通過logon trigger等手段來擷取其中屬于資料庫登入處理的服務時間響應，如圖3-8所示。
（2）session時間響應統計名額：connection management call elapsed time
connection management call elapsed time的時間響應的官方解釋為：花費在執行會話連接配接和會話斷開調用所消耗的時間，機關為微秒。在這個模糊的解釋中，需要界定connection management call elapsed time具體計算的是哪些部分。
從衆多的測試來看，不管連接配接來自于何方，包括tcp遠端連接配接、tcp本地連接配接和本地ipc連接配接，connection management call elapsed time大緻保持穩定。可以認為connection management call elapsed time不包含用戶端處理、listener處理和服務程序的派生時間。從後續的權限集合、session aduit以及logon trigger測試來看，connection management call elapsed time至少包含了session建立之後的所有非空閑時間。從audses$的測試可以看出，connection management call elapsed time應該包含資料庫session初始化過程；從db time和connection management call elapsed time的差異來比較，可以認為connection management call elapsed time不包含程序資訊初始化的過程和使用者密碼最後驗證的過程。
connection management call elapsed time的時間響應計算方式是：從資料庫session建立到登入驗證結束階段的流程響應時間（非空閑時間），注意其中不包含傳回用戶端的響應時間。該名額可以很好地描述在資料庫登入過程中，資料庫内部發生的流程和執行的操作。從測試來看，connection management call elapsed time的時間響應變化基本在5～10ms之間（不包含session audit和logon trigger）。connection manaement call elapsed time的統計值如圖3-9所示。
（3）session時間響應名額：db time
db time的計算顯然不可能包含用戶端響應和listener處理時間，關鍵需要确認是否包含服務程序派生過程。可以通過簡單比較本地tcp連接配接和本地ipc連接配接來确定db time的組成，本地ipc連接配接不包含程序派生時間，僅包含程序初始化過程。本地ipc連接配接的db time和db cpu統計如圖3-10所示。
本地tcp連接配接的db time和db cpu統計如圖3-11所示。
我們無法判斷這兩者之間的差別，并且可以看到db cpu在本地ipc連接配接中db cpu很有可能會大于db time。在本書中，我們采用以下時間響應描述。
db time：從程序初始化開始的資料庫登入流程。
db cpu：db cpu的計算包含了程序派生過程。
db time的本地tcp連接配接和ipc連接配接的時間響應範圍多數在10～30ms之間（不包含session audit和logon trigger）。
（4）資料庫登入流程實際響應時間
無論是db time、db cpu還是connection management call elapsed time，都不包含空閑等待事件，從本質上來看，db time的計算還是從cpu的觀點來看待問題，而不是從流程的觀點來看待問題的。正是因為看待問題的角度不同，産生了資料庫登入流程的實際響應時間與db time産生了比較大的差異。從多次的測試來看，本地連接配接的時間響應基本在110ms以上，很少會超過150ms，遠端連接配接基本在150ms以上，很少會超過220ms。
實際響應時間和db time的比較（sesstime1.sql）描述如下。
遠端tcp連接配接。
real elapsed time = 170ms
本地tcp連接配接。
real elapsed time = 130ms
本地ipc連接配接。
sesstime1.sql腳本代碼如下：
（5）session時間響應名額：db time、session audit和logon trigger
可以通過session audit的觸發器來衡量session audit的時間響應與db time之間的關系。以下代碼可以建立資料庫登入審計，并且在aud$表格中建立觸發器來衡量db time和session audit的反應。
sesstime1.sql進行驗證響應的結果如下，顯然db time中包含了session audit時間。
real elapsed time = 21770ms
下面再來看logon trigger是否也是同樣的情形，使用disable session audit語句建立logon trigger。
再次用sesstime1.sql進行驗證，很明顯，db time包含了logon trigger的運作時間。
real elapsed time = 22570ms
3.2.2 輸入壓力與輸出響應之間的關系
1.?輸入壓力與輸出響應之間關系的測試
回顧資料庫登入流程的處理過程和輸出響應名額。
這裡已經明确獲得了兩個輸出響應名額：db time和connection management call elapsed time，分别描述了logon response time的一部分。再來看看随着輸入壓力的持續增大，輸出響應時間會有什麼樣的反應：logon response time、db time和connection management call elapsed time。
這裡用sesstime2.sh來進行輸入壓力模拟：
下面來看上述運作的典型值：
connection management call elapsed time從正常的5～10ms增長到了198ms，db time從正常的10ms增長到了200ms。從db cpu和wait event可以看出，db time和connection management call elapsed time的增長貢獻與資料庫操作本身沒有太大關系，主要貢獻來源于短時間内有大量的程序同時派生，導緻cpu無法及時處理程序派生和程序初始化，尤其是程序派生過程中包含了派生程序和listener之間的握手。
下面用tnsping來測試listener的輸入：
在大量的tnsping壓力下，listener的處理能力并沒有發生大的變化，主要原因在于tnsping并不需要派生服務程序，進而使tnsping指令可以被快速處理。但是當有大量服務程序派生的時候，listener程序服務需要不斷與服務程序進行握手。由于服務程序響應緩慢，導緻listener的服務隊列很快撐滿，進而使listener處理能力大幅度下降。比如，在高壓力的listener運作下，tnsping的反應如下：
2.?資料庫登入流程輸入/輸出響應名額的确定
從輸入壓力和輸出響應之間關系的測試可以知道，db time和connection management call elapsed time可以很好地反映資料庫登入的輸入壓力，尤其是connection management call elapsed time反映資料庫登入的專業描述，後續的業務通路并不會增加該名額值。connection management call elapsed time反映了登入流程的程序（session）初始化和資料庫内部操作，而tnsping的響應速度慢則反映了服務程序派生緩慢導緻的問題。顯然，兩者結合就可以判斷資料庫登入流程在哪個環節出現了問題。
最終，資料庫登入流程可以由以下主要名額構成。
以下是輸入名額：
logons：合計登入次數。
以下是輸出名額：
connection management call elapsed time：關鍵資料庫連接配接管理時間的消耗。
db time：輔助資料庫連接配接管理時間的消耗，可以不記錄。
listener response time：衡量listener的處理能力，利用tnsping獲得。
network response time：衡量網絡的響應能力，利用ping獲得。
network wait time：衡量網絡和用戶端的響應能力，利用事件等待獲得。
client request time：用戶端預處理時間，目前不可衡量。
整體的logon response響應時間可以用公式大緻描述如下：
logon response time = client request time + network response time × 6
+ listener response time + db time(connection management call elapsed time)
+ network wait time
由于在需要優化的時候，logon response time會成為一個已知值，在隻有一個未知client request time的情況下，client request time就成為一個可以推算的值，我們自然可以依據上述公式來判斷資料庫登入流程在哪個環節出現了問題才會導緻資料庫登入緩慢。
可以通過logon response time的變種來簡化資料庫登入流程的性能優化：
logon response time = network response time × 10 + native tcp logon
= network response time × 10 + listener response time + native ipc logon time
3.?listener.log和資料庫登入流程輸入壓力
有時候可能會缺乏對應輸入壓力（logons per second）的資料，oracle listener元件的日志提供了細節性的感性認知資料。可以用cat listener.log|grep connect_data過濾檔案内容，得到listener連接配接資料，代碼如下
顯然，從檔案中可以得到logons per second輸入壓力名額、資料庫登入請求的主要源節點（ip位址和主機名），以及主要的應用程式等資訊。
如果關心某個時間段的logons per second資訊，也可以簡單地通過listener service指令獲得，通過established的值時間快照差計算獲得logons per second：
4.?資料庫登入流程輸入/輸出關系曲線圖
下面先用以下腳本（sessiontime3.sh）收集資料：
得到的并行logon和響應時間的關系圖如圖3-12所示。
再用下面的腳本收集資料。
得到的并行logon輸入和db time的輸出響應時間關系圖如圖3-13所示。
以上資料是從筆者筆記本的虛拟機中獲得的，由于資源有限，是以受到資源響應的沖擊很大，但也基本反映了logon吞吐量和響應時間輸出之間的關系。随着logon并行次數的增加，輸出響應時間随之變大。
3.2.3 資料庫登入流程響應問題的優化案例
1.?案例描述一：頻繁短連接配接的業務系統
場景描述：某營運商電子運維系統（hp rx6600/oracle 10.2.0.4）遭遇業務系統性能故障，幾乎每1～2個星期就由于業務系統響應緩慢需要重新啟動主機。主機可以進行遠端撥号
通路。
優化過程：從描述來看，似乎這又是一個簡單的hp-ux的交換空間預設配置問題，撥号登入系統之後進行如下系統檢查。
檢查hp-ux交換空間配置，正常。
進入資料庫檢查，資料庫處于輕載運作狀态，唯一感覺有問題的就是logons偏高，達到每秒40多個。
回到作業系統檢查，資源表現正常。
listener程序cpu占有率偏高，本地tnsping響應慢。
本地ipc連接配接響應很快，本地tcp連接配接響應緩慢。
檢查netstat輸出，發現較多的time_waited連接配接，表示存在着大量頻繁退出的連接配接，與資料庫内部logons偏高一緻。
檢查listener.log，每秒産生大量的連接配接，幾乎所有的連接配接都來自于中間件伺服器。
告知使用者檢查中間件連接配接池，估計是連接配接池參數配置不當或者沒有使用連接配接池所引起的。
使用者咨詢開發人員之後确認，系統沒有采用連接配接池管理。
優化結論和改善如下。
本系統顯然是一個輕載型系統，偶爾的高并發性業務導緻業務系統性能故障。
短連接配接的業務響應時間包含了資料庫連接配接過程。
改變短連接配接為連接配接池管理。
如果在開發人員完成連接配接池管理之前遇到類似問題，大多數情況下（非持續性高壓力通路），可以通過重新啟動listener而不是重新開機主機解決。
2.?案例描述二：連接配接池參數設定不當
場景描述：某工商局業務系統間歇性表現為業務系統性能不佳，在持續的卡殼之後可以自我恢複。自我性能恢複似乎與業務系統吞吐量并沒有太大的關系。
優化過程如下。
檢查典型時段的awr報告，顯然資料庫處于輕載運作狀态。
排除資料庫問題，業務性能緩慢應該是由連接配接池管理問題引起。
使用者檢查連接配接池，在問題出現的時候往往空閑連接配接池的數量很少。
考慮到使用者業務系統性能與業務系統吞吐量高低并沒有直接關系，似乎不是中間件的bug或者其他系統性障礙。
讓使用者檢查中間件活動連接配接增長狀況和min-max配置。
連接配接池參數配置為min = 5，max = 500，正常活動狀況為30左右。
綜合來看，應該是連接配接池配置管理不當引起的，設定min = 100。
由于connection pool的最小連接配接池參數設定過小，是以連接配接池管理不斷釋放可用連接配接，導緻後續業務無法從connect pool中獲得連接配接，需要進行動态擴張。
頻繁的動态擴張連接配接，使業務系統響應包含了資料庫登入過程，導緻業務系統反應
緩慢。
檢查增加連接配接池管理，使最小連接配接到合适的大小即可。
建議中間件連接配接池的最小連接配接和最大連接配接的參數保持相同，避免動态擴充和回收。
建議以連接配接池管理綜合硬體能力和業務需求來進行設定，而且以硬體能力為主，業務需求輔助。
3.?案例描述三：資料庫登入sequence cache不足導緻資料庫登入緩慢
場景描述：某醫院his業務系統的賬戶登入操作異常緩慢，部分情況下甚至會出現長時間的卡殼，業務影響主要發生在每天早上的上班時刻。
賬戶登入過程一般涉及在賬戶表格以及對應日志表格上的沖突，比如buffer busy waits或者tx lock，awr未展現該特征。
awr報告顯示connection management call elapsed time時間偏長，sequence load elapsed time具有一個明顯偏大的值。
即使在經常發生性能問題的上班時刻，tnsping的表現也相對比較正常，說明listener處理正常。
檢查sequence audses$的cache設定，發現該值為20，與早上上班的高峰期資料庫登入有些不比對，增加audseq$的cache值到10?000。
sequence audses$的cache大小不足是導緻資料庫登入響應緩慢的主要原因。一般情況下，該值在20時并不會産生問題，隻有在大量高并發登入的時候才會有問題。
修改sequence audses$的cache值為10?000，以支援同一時間段的大批量資料庫登入。