江苏快三开奖结果

隨筆-95  評論-224  文章-24  trackbacks-0
1. 綁定變量作為一種優化查詢處理的方法,在性能上有利有弊,是一把雙刃劍。它的優勢在于可以共享庫緩存中的父游標,從而避免了硬解析及相關的開銷;劣勢在于因綁定變量掃視增加了查詢優化器選擇(非常)低效執行計劃的風險,即使支持自適應游標共享,也引入了游標感知判斷和謂詞選擇率估算的代價,而且在生成高效的執行計劃前至少有一次是無效率的。因此,是否使用綁定變量,需要衡量實際字面值與處理數據量帶來的解析執行的收益與損害,當損害大于收益時就不應該使用,反之當處理較少數據硬解析耗時比執行多時,就可以使用了

2. 存儲快照一般有三種層次:物理卷、文件系統和應用程序
   ◆ 物理卷快照基于卷扇區映射表實現,宜采用CoFW法,因為它不必每次寫io都去遍歷映射表,比RoFW快
   ◆ 文件系統快照基于inode樹即元數據復制實現,每當寫io時更新快照或源inode的指向,必要時向上回溯至根inode。有的文件系統比如NetApp公司的WAFL則更優,只須復制根inode,因為每次寫io時它會變但其下所有的inode不會變
   ◆ 應用程序快照最典型的就是數據庫,原理本質與上述兩種一樣,基于頁改變位圖,當page首次(相對于快照創建時刻)改變時拷貝到快照文件(一種稀疏文件),另外當撤消未提交事務或回滾事務時也會發生拷貝(此時快照慢慢不再稀疏),這是為了保證快照的可用一致性

3. 數據塊的加鎖有單機和分布式兩種情景,前者是為了同步單實例事務的并發,后者是為了協調分布式事務的同步,并與緩存一致性協議緊密聯系。undo,redo,undo/redo三種日志對數據臟塊與提交日志記錄落盤的順序要求各不同,因此恢復方式不同。脫服務器備份架構比較好,具有不占用應用服務器資源的優勢,而微軟的vss可傳輸卷影拷貝提供了這一支持,足見其技術的先進前瞻性

4. Oracle的實例恢復完全靠在線重做日志,介質恢復必須靠歸檔重做日志,以及在線重做日志。然而在線重做日志是有限數量的,那么Oracle是怎樣保證宕機經實例恢復后不丟數據?答案是檢查點。檢查點是數據庫中一個很重要的機制,被重做日志切換觸發,由DBWn執行刷新臟塊,并清除老的無用的在線重做日志,以允許被覆蓋

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的專用數據結構而不像后者重用了頁緩存,內存區的映射完全由內存管理器負責包括物理頁分配及臟頁面寫入器,與緩存管理器無關;緩存管理器基于內存管理器維護了文件塊數據的視圖,并提供了自己的延遲寫入器。這兩種寫入器即回刷,獨立并行地工作
posted on 2019-11-06 11:29 春秋十二月 閱讀(1122) 評論(0)  編輯 收藏 引用 所屬分類: Database

只有注冊用戶登錄后才能發表評論。

網站導航:                管理