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

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

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

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

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

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

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

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

13. Oracle數(shù)據(jù)庫究竟是怎樣構(gòu)建表數(shù)據(jù)塊的讀一致性版本？這是個比較復(fù)雜、細(xì)致和有趣的問題，核心流程如下

   ◆ 克隆數(shù)據(jù)塊，若不存在則先從磁盤讀，下面幾步以克隆塊為目標(biāo)

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

   ◆ 根據(jù)ITL中的uba，反向更改所有未提交的事務(wù)，也就是應(yīng)用事務(wù)的undo記錄

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

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

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

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

17. 相容性矩陣是封鎖調(diào)度的核心結(jié)構(gòu); 任意一個無環(huán)優(yōu)先圖的封鎖調(diào)度都是沖突可串行化的; 基于樹協(xié)議的無環(huán)優(yōu)先圖的封鎖調(diào)度，其整個事務(wù)集合的任意一個拓?fù)漤樞蚨际堑葍r可串行化的

18. 總結(jié)解決數(shù)據(jù)庫丟失更新問題的方案

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

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

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

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

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

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

23. 與MySQL不同，Oracle的行鎖無需索引列的限制，是真正的行鎖，其實現(xiàn)為數(shù)據(jù)塊的屬性而非傳統(tǒng)的鎖管理器，但是它需要在事務(wù)commit或rollback時才釋放，如果存在慢sql，那么導(dǎo)致的阻塞會比較嚴(yán)重

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

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