以下的文章主要介紹的是如何正確的檢查Oracle數據庫裡不合理的相關sql語句，我們首先是以代碼的方式來引出相關內容的介紹，如果你對其相關的實際操作有興趣的話，你就可以對以下的文章點擊觀看了。
代碼:
- select sql_text ,sharable_mem from v$sql where sharable_mem > @#100000@# order by sharable_mem ;
上面的sql語句是查詢shared pool中占用內存超過100K的sql語句。
這個sql可以非常有效的檢查出Oracle shared pool中那些嚴重占用內存的sql，根據我的經驗，絕大多數有問題的sql語句都會在這裡留下痕跡，通過在這裡找出有問題的sql語句並進行修改，再反復運行這個sql腳本，直到所以有問題的sql都處理完畢，這就是對Oracle數據庫在sql上面的最好的優化，可以保證不會因為程序員的sql語句問題導致Oracle數據庫的性能問題。
共享池主要由庫緩沖區（共享SQL區和PL/SQL區）和數據字典緩沖區組成。詳細的情況你隨便找一本介紹Oracle內存結構的書上面都有講到。我就不把書上的內容給你打印一遍了，自己去看。
- select * from v$sgastat;
顯式SGA的狀態信息。
有的人寫的SQL語句非常復雜，嵌套了好幾層，SQL語句本身寫的很差，就有可能會占用很大的SQL區域。
其實現實的很多情況是本來不需要那麼復雜的sql的時候，由於程序員水平不夠，寫了那種很糟糕很復雜的sql，造成的Oracle數據庫性能問題。
另外還有一個常識問題，卻很容易被忽略。比如：
代碼:
- select * from table_name where id = 1;
- select * from table_name where id = 2;
對於這種帶參數的sql，id = ? 這個地方叫做站位符(Placeholder)。
拿PHP為例，很多人喜歡這樣寫代碼
代碼:
- $sql = "select * from table_name where id = ";
- $id=1;
- $stmt = ociparse($conn,$sql.$id);
- ocIExecute($stmt);
- ......
- $id = 2;
- $stmt = ociparse($conn,$sql.$id);
- ocIExecute($stmt);
拿Java為例，是這樣的：
代碼:
- String sql = "select * from table_name where id = ";
- Statement stmt = conn.createStatement();
- rset = stmt.executeQuery(sql+"1");
- ......
- rset = stmt.executeQuery(sql+"2");
這種寫法，對於Oracle數據庫來說，完全就是兩條不同的sql語句，
代碼:
- select * from table_name where id = 1;
- select * from table_name where id = 2;
每次查詢都要進行sql語句的執行解析，並且每個sql都會分配一個區域來存放sql解析後的二進制可執行代碼。試想，要是id不同的10萬個sql呢？Oracle就會分配10萬個sql區域來分別存放10萬個這樣的id不同的sql語句。對於一個數據庫驅動的Web網站這樣情況下，SGA開的再大，也會很快被耗盡share pool的，最後報一個ORA-4031錯誤。Oracle數據庫就連接不上了，只好重起。
正確的寫法應該是：
代碼:
- $stmt = ociparse($conn,"select * from table_name where id = :id");
- ocibindbyname($stmt,":id",&$id, 12);
- $id =1;
- ocIExecute($stmt);
- ...
- $id = 2;
- ocIExecute($stmt);
代碼:
- PreparedStatement pstmt = conn.prepareStatement("select * from table_name where id = ?");
- pstmt.setInt(1,1);
- rset = pstmt.executeQuery();
- ...
- pstmt.setInt(1,2);
- rset = pstmt.executeQuery();
這樣Oracle數據庫就知道你實際上用的都是同一條sql語句，會以這樣的形式：
- select * from table_name where id = :1
解析執行後存放在sql區域裡面，當以後再有一樣的sql的時候，把參數替換一下，就立刻執行，不需要再解析sql了。既加快了sql執行速度，也不會占有過多SGA的share pool。
可惜的是，很多程序員明知道這個問題，卻意識不到問題的嚴重性，因為上面那種寫法，編程的時候很靈活，sql語句可以動態構造，實現起來很容易，後面那種寫法，sql語句是寫死的，參數不能再變了，編程經常會非常麻煩。
很多Oracle數據庫的性能問題都是這樣造成的。
有興趣在一個生產系統中，用上面sql檢查一下，看看是否選擇出來的是否l有很多都是一樣的sql語句，只是參數不同，如果是這樣的話，就說明程序員的代碼寫的有問題。
