1、解析是為執行SQL語句做準備的過程，它涉及檢查語句、權限、對像的有效性，以及創建執行計劃（execution plan）。

Oralce共享池（shared pool）中維護了一份SQL語句的緩存，如果在共享池中找到了匹配的SQL語句所對應的解析被稱為軟解析，否則，必須進行硬解析。

硬解析不僅耗費CPU時間，在有大量會話要同時緩存SQL到共享池時還會造成爭用。使用綁定變量並避免不必要的重解析，可顯著降低解析開銷與閂鎖和互斥的爭用。

2、批量檢索記錄可以減少發送到數據庫服務器的請求次數，也可以降低網絡流量和邏輯IO開銷，對於批量查詢來講，批量提取大約可以帶來一個數量級（10倍）的性能提升。

3、應用事務設計的基本目標是持有鎖的時間盡可能短，然而，也不能為了提高並發而犧牲事務的完整性。

悲觀鎖策略--記錄可能會在被提取到與被更新的時間間隔內被其它用戶更新。為避免任何爭用，悲觀鎖要求你在檢索到記錄時立即鎖住此記錄。

樂觀鎖策略--不需要在提取數據時鎖住記錄。然而，為避免記錄在獲取與修改時間內被更新，有必要在事務最終提交DML語句時檢查此記錄是否有發生變化。完成該任務方法有三種：時間戳、最初的數據選擇標準是否仍有效、或用ORA_ROWSCN偽列。

在10G中，ORACLE引入了一個偽列ORA_ROWSCN，訪列為每條記錄包含了一個系統變更號（system change number, SCN），如果表創建時沒有使用rowdependencies關鍵字，則該列只包含了記錄所在數據塊中最大的SCN號。使用ORA_ROWSCN是確認記錄有沒變化最簡單的方法。

樂觀鎖例：

...

select ORA_ROWSCN into v_start_rowscn

from ...;

credit_check(p_cust_id);

update customers_rd

set ...

where cust_id = p_cust_id

and ora_rowscn = v_start_rowscn;

悲觀鎖例：

...

select cust_id into v_cust_id

from customers_rd

where cust_id = p_cust_id for update;

credit_check(p_cust_id);

update customers_rd

set ...

where cust_id = p_cust_id;

數據庫應用設計與實現