【體系結構】深入shard pool

一條sql語句在shared pool中流程:
我們模擬一個環境,當一個用戶進程發出了一條sql語句,select name,age from tab where a=1; 首先服務器進程會先檢查該語句語法正確性,接着通過對照數據字典對語句中涉及的表、索引、視圖等對象及用戶的權限進行檢查即語義檢查(tab表是否存在,用戶是否有相關的權限等),如果以上任一檢查沒有通過,就返回一個錯誤,但不會明確的指出是語法檢查出錯還是語義檢查出錯。
通過檢查,server process會將該語句轉換成ASCII等效數字碼,但如果select *時,當該表中某個字段變化,則轉換的ASCII也是不同的。接着會將該ASCII碼傳遞給hash函數,將其hash得到一個hash值,進程會到shared pool中的libary cache中尋找是否相同的數值, (找的過程是再次對hash過的hash值再hash,然後hash值跟backet鏈編號進行匹配,找到相應的鏈。若找塊,則對物理地址進行hash,找到相應的鏈,進而找到塊。)
如果存在,服務器進程將使用這條語存在SHARED POOL中的已解析過的執行計劃來執行這是軟解析,若只有父遊標沒子游標 需要進行reload.如果不存在,在shared pool找lur 鏈的free chuck(先獲得latch) ,生成父子游標則必須進行以下兩個步驟:語句的優化(生成執行計劃)和生成執行編碼:服務器進程根據ORACLE選用的優化模式以及數據字典中是否存在相應對象的統計數據和是否使用了存儲大綱來生成一個執行計劃或從存儲大綱中選用一個執行計劃,最後再生成一個編譯代碼,這是硬解析。
綁定變量共享sql語句:
解析的過程需要綁定變量,當oracle在shared pool中查找相同的SQL語句的過程中,如果SQL語句使用 了綁定變量(bind variable),那麼就是比較SQL語句的靜態部分,靜態部分是有限的,很容易就能夠緩存在內存裏,從而找到相同的SQL語句的概率很高,達到sql語句共享。如果沒有使用綁定變量,則就是比較SQL語句的靜 態部分和動態部分,而動態部分的變化是無限的,因此這樣的SQL語句很難被緩存在shared pool裏。畢竟內存是有限的,不可能把所有的動態部分都緩 存在shared pool裏,即便能夠緩存,管理這樣一個無限大的shared pool也是不可能完成的任務。不使用綁定變量導致的直接結果就是,找到相同的SQL語句的概率很低,導致必須完整的解析SQL語句,也就導致消耗更多的資源。 從這裏也可以看出,只有我們使用了綁定變量才能夠更有效的利用shared pool。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章