5. Linux內(nèi)核的swap高速緩存和其它的緩存(比如page緩存)不太一樣，因?yàn)樗嬖诘闹饕虿皇菫榱藴p少磁盤(pán)IO提高性能，而是解決換入換出共享匿名頁(yè)同步即并發(fā)swap的問(wèn)題。那么它是唯一的方法嗎？不一定，可以遍歷所有的anon_vma鏈表，查找匿名頁(yè)對(duì)應(yīng)的頁(yè)框是否已建立，但該方法沒(méi)有swap緩存快。當(dāng)然，在換入操作很多的情景，swap緩存確實(shí)能提高系統(tǒng)性能

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

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

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

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

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

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

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ù)庫(kù)究竟是怎樣構(gòu)建表數(shù)據(jù)塊的讀一致性版本？這是個(gè)比較復(fù)雜、細(xì)致和有趣的問(wèn)題，核心流程如下

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

24. 隔離是實(shí)現(xiàn)安全的一種辦法，其結(jié)果常被稱作“沙箱”。從這個(gè)意義上講Oracle很明智，因?yàn)樗氖聞?wù)沒(méi)有也不需要read uncommitted隔離級(jí)別，Oracle最低且默認(rèn)的隔離級(jí)別是read committed，因?yàn)樗谢趗ndo的多版本控制，天生非阻塞讀，根本不會(huì)臟讀。我想不出read uncommitted有什么好處，除了非阻塞讀及可能的高并發(fā)，要謹(jǐn)慎臟讀是危險(xiǎn)不安全的

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