程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> Oracle數據庫 >> Oracle教程 >> Oracle核心技術筆記(該書讀得不仔細,需要找時間再細讀~~)

Oracle核心技術筆記(該書讀得不仔細,需要找時間再細讀~~)

編輯:Oracle教程

Oracle核心技術筆記(該書讀得不仔細,需要找時間再細讀~~)


Oracle核心技術

跳轉至: 導航、 搜索

目錄

  • 1 開始
  • 2 redo和undo
  • 3 事務與一致性
  • 4 鎖與闩
  • 5 緩存和復制
  • 6 寫入和恢復
  • 7 解析與優化
  • 8 RAC及‘缺陷’
  • 9 附錄A 轉儲與調試

    開始

    SGA/SCN真正需要理解的僅僅3個進程:lgwr、dbwr、dbwN

    redo和undo

    Oracle v6:改變向量(change vector)兩份存儲:當前狀態 + redo日志改變數據的方法:4步關鍵步驟(這使得數據修改是可逆的) 創建改變操作的描述(redo change vector)undo描述(插入到undo表空間的undo塊中)undo描述的描述(此undo的redo change vector)改變數據項 實際的順序變成3 1 2 4,2條redo被合並為一條日志記錄,寫入到redo緩沖區事務中的第一次修改包含一些特殊步驟*(我的小結)理論上說來,redo日志寫成功即意味著事務已經成功提交,這時如果數據庫崩潰導致內存中的當前狀態沒有更新到數據庫存儲中時,就可以通過redo再做一次以確保事務完成;另外一方面,由於一個嵌套事務的失敗,導致已完成的數據庫更新需要回退,這時就需要undo,而undo本身有可能因存儲於易失性區域崩潰而丟失,這時就需要把undo再通過undo的redo日志再做一遍以恢復數據到前一個一致狀態 從上面的描述可以看到,事務的實現依賴於數據修改是可逆的這一點,否則狀態易失(如賦值操作、文件寫操作)就不可能做到一致性恢復而一致性恢復依賴於全局一致性快照(即MVCC)的創建,為此需要事務號、時間戳這些特殊的底層屬性來實現,這可以參考CLojure語言中相關概念 why?undo記錄阻止了其他用戶查看我們正在改變的數據(中間臨時狀態) 其他用戶可以通過undo得到記錄的之前的一個版本(與他的事務視圖相一 redo allocation latch:保護redo日志緩沖區(因為只有一個lgwr進行著串行的寫操作) 所謂的latch其實就是Linux Kernel裡類似spin_lock(自旋鎖)的東西 p17 每個人都做一點點“額外的”工作(協作的開銷?),就意味著他們可以在不同的地方同時工作,而不必經常在同一個地方競爭(contention)redo simplicityundo complexity undo的存在能夠讓會話在不應該看到數據的最新版本(未事務提交!)時去訪問更舊的版本(與會話的一致性相符合)讀一致性:有限的ITL entries,超出的作為undo記錄保存(往回倒帶~)回滾:將產生新的redo!(請對照代碼管理系統裡的revert操作,revert實際上產生一個新的commit) 消除回滾成本:全局臨時表

    事務與一致性

    讓提交盡可能快*,讓回滾慢慢來 *並且盡可能頻繁?細粒度的提交對VCS而言有助於連續集成,對於DBMS呢? 事務與undo undo段:段頭、extent map、extent control header事務表TRN TBL:,wrap#列? 事務表中條目,在v$transaction視圖裡稱‘槽’(slot) x$ktuxenewing, & 閃回。。。單個undo塊可包含多個事務的undo記錄 數據塊訪問與undo 本節包含的內容相當重要,但由於涉及大量細節,只能等有時間的時間再細看了 提交SCN 提交清除延遲塊清除:通過“均攤”的方式來‘隱藏’工作量事務表回滾 ORA-1555 “快照太舊” 大對象(LOB) 只需關心索引的事務和讀一致性處理,特例:ORA-22924 小結 一個ITL條目:xid: uba: SCN

    鎖與闩

    鎖和pin:FCFS;闩和Mutex(10g+,替換pin):隨機搶占策略闩:保護共享內存 可共享本質上是一個內存位置和一個test-and-set的CPU原子操作的組合(#see Lock-Free數據結構)相當於Linux內核裡的spin_lock,spin_lock在單核CPU下不起作用活動統計:v$latch_parent v$latch_children gets、misses、spin_gets、sleeps、sleepN、immediate_gets、immmediate_misses、wait_time 等待喚醒機制(相當於Linux內核裡的信號量?)library cache latch 大部分闩鎖在11g中取消了(只剩library cache load lock) 鎖:保護對象(鎖=排隊?) 基礎結構:x$ksqrs(v$resource,標記資源) x$ksqeq(設置鎖模式)v$lock “鎖定”某個對象:加入到等待隊列某尾,直到等待隊列和轉換隊列之間沒有會話在你前面,這時附加自己到擁有者隊列 死鎖 TX/4等待? 鎖模式 NL SS RS SX RX S SSX SRX X 保護鎖的闩鎖*KGL鎖(和pin)鎖和pin=〉11g後逐步被Mutex替代

    緩存和復制

    內存管理 10g ASMM:db_cache_size/shared_pool_size ==> 固定大小的granule 多個數據塊緩存 8種類型:db_cache_size db_keep_cache_size db_recycle_cache_size db_2k_cache_size(這什麼破命名) ...更小的chunk 工作集 x$kcbwds LRU/TCH算法 似乎比較重要,待有時間重新細讀 REPL_AUX --> REPL_MAIN? 查找數據 pin住緩存區邏輯IO更新載入hash鏈讀一致性拷貝物理IO表掃描

    寫入和恢復

    lgwr redo sync writes和log file sync10g+ 新的commit選項重做日志浪費(redo wastage)私有重做(private redo threads) dbwr 緩沖區頭部檢查點隊列增量檢查點 寫進程的交互 ?相對文件號()/絕對文件號(afn:) 恢復

    解析與優化

    數據字典緩存:v$sgastat8i+ cursor_sharingparse活動和parse call?庫緩存共享池解析和優化(略)executing、locking和pinning

    RAC及‘缺陷’

    GRDp178 虛擬IP和SCANp183 至少需要從4個實例開始Master和ShadowGCS和GES緩存融合

    附錄A 轉儲與調試

    1. 上一頁:
    2. 下一頁:
    Copyright © 程式師世界 All Rights Reserved