5. Linux內核的swap高速緩存和其它的緩存(比如page緩存)不太一樣，因為它存在的主要原因不是為了減少磁盤IO提高性能，而是解決換入換出共享匿名頁同步即并發swap的問題。那么它是唯一的方法嗎？不一定，可以遍歷所有的anon_vma鏈表，查找匿名頁對應的頁框是否已建立，但該方法沒有swap緩存快。當然，在換入操作很多的情景，swap緩存確實能提高系統性能

6. Linux內存回收的核心是LRU鏈表，Oracle的buffer cache也有個LRU，這兩種LRU的共同點是引用計數(標志)和非活躍鏈表，引用計數會影響一個對象是否移到非活躍鏈表，非活躍鏈表用于回收或覆蓋這個對象。對于Linux這個對象是頁框，移到非活躍鏈表取決于swap tendency；而Oracle則是數據塊buffer及其TCH

7. Linux內核中的反向映射讓我想起了Oracle中的反向鍵索引，它們的共同點都是為了高性能，前者是為了快速定位引用同一頁框的所有頁表項，從而方便共享內存的回收；后者是為了減少右側索引葉塊的競爭，從而降低緩沖區忙等待、提高并發量

8. mvcc與read uncommitted(簡稱RU)隔離級別的關系究竟如何？這取決于現代數據庫的實現。對于Oracle，RU和RC的讀實現都基于mvcc實現，換句話說Oracle其實沒有臟讀；對于MySQL innodb引擎，mvcc不適用于RU而只適用于RC/RR級別，因為RC/RR必須讀取修改已提交的數據，但基準點不同，前者查詢開始時、后者事務開始時，而RU則可讀取未提交的數據，當然用mvcc模擬實現RU應該也可以，只需要讀取當前新版本而非舊版本

9. 借助內核page cache的數據庫或者存儲引擎，一定程度上講，是粗暴懶惰的表現，這會導致系統負載比較重的情況下，io性能很差。所以為高性能，必須得處理好direct io，設計self cache，這樣一來，就避免了浪費在原先內核頁緩存的頁框，避免處理內核頁緩存和預讀的多余指令而提高了系統調用read和write的效率，同時減少了一次數據拷貝

10. SQL半連接的本質是在內連接的基礎上對內表去重，即使內表有符合多個連接條件的元組，也只匹配一條，從而減少了連接返回的結果集。一般地，簡單的in、exists和any子句，都采用半連接實現，但若內表本身保證了唯一性，則半連接可消除轉為內連接實現，或者內表數據量很小且外表存在索引，那么也會消除半連接，生成由內表驅動外表，外表走索引的執行計劃。由此一例看出，SQL優化器偏愛內連接，因為內連接帶來了驅動表選擇和謂詞下推的靈活，便于產生更優的執行計劃

11. 從Oracle數據庫內核角度講，游標代表SQL語句的句柄，包含了依賴對象及執行計劃等信息，它相當于linux的文件描述符和windows的句柄。打開或緩存的游標是指對應SQL語句所占的內存(父游標句柄、父堆0和子游標句柄的chunk)被加上kgl lock和pin鎖，意味著第三次后解析同樣的SQL不必再從library cache hash chain中加鎖查找而直接從PGA的子堆6地址中獲取并調用執行計劃，如此優化提高了并發度加快了查詢，這正是軟軟解析；軟軟解析前必須軟解析2次，目的是將library cache的執行計劃在PGA中做一份鏈接，軟解析前必須硬解析，目的是將執行計劃放在library cache中。然而，如果共享池空閑內存不足，或者依賴對象發生DDL操作導致執行計劃失效，那么執行計劃所占chunk可以被覆蓋釋放，這樣一來，軟(軟)解析時就需要重新生成執行計劃了

12. Oracle的內存管理粗略地類似于Linux內核，所不同的是內存分配單元，前者叫granule通常大小4M~16M，后者叫page通常4K；數據塊緩沖的分配類似伙伴算法，共享池(主要用于sql緩存)的chunk分配類似slab算法，共享池中的保留池類似基于slab的內存池

13. Oracle數據庫究竟是怎樣構建表數據塊的讀一致性版本？這是個比較復雜、細致和有趣的問題，核心流程如下

   ◆ 克隆數據塊，若不存在則先從磁盤讀，下面幾步以克隆塊為目標

   ◆ 根據ITL中的flag及lck，對所有已提交的事務做清除操作，即延遲塊清除。延遲塊清除為了獲取足夠精確的提交SCN填充到ITL，分2種情況，若事務表槽沒被覆蓋，則直接用其提交SCN；否則先從事務控制區獲取SCN，并判斷對于上界提交是否足夠精確，若不夠則需要回滾事務表一直找到合適的SCN或報錯ORA-01555

   ◆ 根據ITL中的uba，反向更改所有未提交的事務，也就是應用事務的undo記錄

   ◆ 根據ITL中的SCN，不斷反向更改大于目標SCN的已提交事務，直至遇見合適的已提交事務。這里也是應用undo記錄，但不同的是，除了應用行數據，還會從事務的第一個undo記錄找到先前即前一個已提交事務的ITL項拷貝回當前塊的對應ITL項

14. Oracle的多版本控制機制，為dml不僅提供了一致且正確的結果，還提高了并發性，可謂魚和熊掌兼得。那么它的缺點是什么？可能會導致熱表的IO增高，因為讀一致性需要不斷回滾多個事務對數據塊的修改，直到查詢開始時的數據。事務隔離級別read committed與read uncommitted的相同是不會臟讀，區別是前者會不可重復讀或幻讀

15. Sql*plus的ARRAYSIZE對查詢數據性能有重要的影響，這個值過大過小都不好，而是要接近一個數據塊所擁有的行數，如此僅一次邏輯IO就拿到了一批行。那么設置合適的ARRAYSIZE就一定能提高性能嗎？不一定，還要看所查詢的表使用了什么索引列及表數據在磁盤上的物理布局，若數據分散即聚簇因子低，則優化器會選用全表而非索引區間掃描，去執行這個查詢

16. IOT表如果為非主鍵列再建索引，那么就成二級索引。這時候查詢數據，需要兩次掃描，一是掃描二級索引得到IOT中的位置，二是掃描IOT本身匹配那個位置，之所以這樣是因為行記錄在IOT中的位置會變。而堆組織表，僅需一次掃描索引結構，得到rowid，再直接讀磁盤獲取行記錄。因此IOT上再建二級索引，并非明智的選擇

17. 相容性矩陣是封鎖調度的核心結構; 任意一個無環優先圖的封鎖調度都是沖突可串行化的; 基于樹協議的無環優先圖的封鎖調度，其整個事務集合的任意一個拓撲順序都是等價可串行化的

18. 總結解決數據庫丟失更新問題的方案

     ◆ 對于表不會被悲觀鎖鎖定的情景：使用基于select+update的樂觀鎖方法，查詢保存前映像，以便定位更新。前映像列可為全列，或新增一個時間戳列作為版本列

     ◆ 對于表可能會被悲觀鎖鎖定的情景：使用select…for update nowait+update的悲觀鎖方法，可以以全列的hash(虛擬列)來定位更新

19. 如果能夠在備庫上打開閃回，那么就可以做到既讓生產系統沒有承擔閃回的開銷，又能快速地為錯誤或故障恢復到以前某個時刻。一舉兩得比較完美，重做日志的創新使用真是太棒了

20. Oracle的索引聚簇表是個創新，它能將多個不同表的行按照索引列存儲在同一塊中，屬于物理上的join，這樣一來既可減少data buffer緩存的塊數而提高效率，又可提高多個相關表連接查詢的性能，比如通過外鍵約束的父子表。最典型的應用就是數據字典，數據字典對于查詢優化的成本估算很重要，由此可見oracle的設計之明智，mysql的innodb只有索引組織表，sql server有堆表和索引組織表，但它們都沒有索引聚簇表

21. 分布式事務處理是工程難題。Oracle的serializable串行隔離級別以樂觀鎖實現，所以并發度與非串行相當，需要注意的是：串行并不是說一個事務提交了才能處理下一個，而是多個事務間沒有沖突表現地像只有一個事務在運行，否則Oracle的serializable級別就不存在拋出ORA-08177錯誤了

22. 理清read uncommitted事務隔離級別的鎖策略：讀不加共享鎖，寫加排它鎖直至提交，這里的鎖是指lock；塊的緩沖區并發操作必須加鎖，這里的鎖是指latch，若不加，那臟讀讀到的數據可能是錯的。臟讀隔離級別允許讀修改但未提交的行記錄，這意味著讀不能被寫阻塞，也不能阻塞寫，所以不會申請共享鎖（顯式鎖定讀除外）

23. 與MySQL不同，Oracle的行鎖無需索引列的限制，是真正的行鎖，其實現為數據塊的屬性而非傳統的鎖管理器，但是它需要在事務commit或rollback時才釋放，如果存在慢sql，那么導致的阻塞會比較嚴重

24. 隔離是實現安全的一種辦法，其結果常被稱作“沙箱”。從這個意義上講Oracle很明智，因為它的事務沒有也不需要read uncommitted隔離級別，Oracle最低且默認的隔離級別是read committed，因為它有基于undo的多版本控制，天生非阻塞讀，根本不會臟讀。我想不出read uncommitted有什么好處，除了非阻塞讀及可能的高并發，要謹慎臟讀是危險不安全的

25. windows內存映射和linux內存映射的實現機制不太一樣，前者使用了內存區section的專用數據結構而不像后者重用了頁緩存，內存區的映射完全由內存管理器負責包括物理頁分配及臟頁面寫入器，與緩存管理器無關；緩存管理器基于內存管理器維護了文件塊數據的視圖，并提供了自己的延遲寫入器。這兩種寫入器即回刷，獨立并行地工作