開始

1. SGA/SCN
2. 真正需要理解的僅僅3個進程：lgwr、dbwr、dbwN

redo和undo

1. http://www.vxbq.cn/oracle/ v6：改變向量（change vector）
2. 兩份存儲：當前狀態 + redo日志
3. 改變數據的方法：4步關鍵步驟（這使得數據修改是可逆的）
   1. 創建改變操作的描寫（redo change vector）
   2. undo描寫（插入到undo表空間的undo塊中）
   3. undo描寫的描寫（此undo的redo change vector）
   4. 改變數據項
   • 實際的順序變成3 1 2 4，2條redo被合并為1條日志記錄，寫入到redo緩沖區
   • 事務中的第1次修改包括1些特殊步驟*
   • （我的小結）理論上說來，redo日志寫成功即意味著事務已成功提交，這時候如果http://www.vxbq.cn/db/崩潰致使內存中確當前狀態沒有更新到http://www.vxbq.cn/db/存儲中時，就能夠通過redo再做1次以確保事務完成；另外1方面，由于1個嵌套事務的失敗，致使已完成的http://www.vxbq.cn/db/更新需要回退，這時候就需要undo，而undo本身有可能因存儲于易失性區域崩潰而丟失，這時候就需要把undo再通過undo的redo日志再做1遍以恢復數據到前1個1致狀態

     從上面的描寫可以看到，事務的實現依賴于數據修改是可逆的這1點，否則狀態易失（如賦值操作、文件寫操作）就不可能做到1致性恢復

     而1致性恢復依賴于全局1致性快照（即MVCC）的創建，為此需要事務號、時間戳這些特殊的底層屬性來實現，這可以參考CLojure語言中相干概念

4. why？undo記錄禁止了其他用戶查看我們正在改變的數據（中間臨時狀態）
   1. 其他用戶可以通過undo得到記錄的之前的1個版本（與他的事務視圖相1
5. redo allocation latch：保護redo日志緩沖區（由于只有1個lgwr進行著串行的寫操作）
   1. 所謂的latch其實就是Linux Kernel里類似spin_lock（自旋鎖）的東西
6. p17 每一個人都做1點點“額外的”工作（協作的開消？），就意味著他們可以在不同的地方同時工作，而沒必要常常在同1個地方競爭(contention)
7. redo simplicity
8. undo complexity
   1. undo的存在能夠讓會話在不應當看到數據的最新版本（未事務提交?。r去訪問更舊的版本（預會話的1致性符合合）
   2. 讀1致性：有限的ITL entries，超越的作為undo記錄保存（往回倒帶~）
   3. 回滾：將產生新的redo?。ㄕ垖Ρ却a管理系統里的revert操作，revert實際上產生1個新的commit）
      1. 消除回滾本錢：全局臨時表

事務與1致性

1. 讓提交盡量快*，讓回滾漸漸來
   1. *并且盡量頻繁？細粒度的提交對VCS而言有助于連續集成，對DBMS呢？
2. 事務與undo
   1. undo段：段頭、extent map、extent control header
   2. 事務表TRN TBL:，wrap#列？
      1. 事務表中條目，在v$transaction視圖里稱‘槽’（slot）
   3. x$ktuxe
   4. newing, & 閃回。。。
   5. 單個undo塊可包括多個事務的undo記錄
3. 數據塊訪問與undo
   1. 本節包括的內容相當重要，但由于觸及大量細節，只能等有時間的時間再細看了
4. 提交SCN
   1. 提交清除
   2. 延遲塊清除：通過“均攤”的方式來‘隱藏’工作量
   3. 事務表回滾
      1. ORA⑴555 “快照太舊”
   4. 大對象（LOB）
      1. 只需關心索引的事務和讀1致性處理，特例：ORA⑵2924
5. 小結
   1. 1個ITL條目：xid: uba: SCN

鎖與閂

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

緩存和復制

1. 內存管理
   1. 10g ASMM：db_cache_size/shared_pool_size ==> 固定大小的granule
2. 多個數據塊緩存
   1. 8種類型：db_cache_size db_keep_cache_size db_recycle_cache_size db_2k_cache_size（這甚么破命名） ...
   2. 更小的chunk
3. 工作集
   1. x$kcbwds
4. LRU/TCH算法
   1. 似乎比較重要，待有時間重新細讀
5. REPL_AUX
   1. --> REPL_MAIN？
6. 查找數據
   1. pin住緩存區
   2. 邏輯IO
   3. 更新
   4. 載入hash鏈
   5. 讀1致性拷貝
   6. 物理IO
   7. 表掃描

寫入和恢復

1. lgwr
   1. redo sync writes和log file sync
   2. 10g+ 新的commit選項
   3. 重做日志浪費（redo wastage）
   4. 私有重做（private redo threads）
2. dbwr
   1. 緩沖區頭部
   2. 檢查點隊列
   3. 增量檢查點
3. 寫進程的交互
   1. ？相對文件號（）/絕對文件號（afn:）
4. 恢復

解析與優化

1. 數據字典緩存：v$sgastat
2. 8i+ cursor_sharing
3. parse活動和parse call？
4. 庫緩存
5. 同享池
6. 解析和優化（略）
7. executing、locking和pinning

RAC及‘缺點’

1. GRD
2. p178 虛擬IP和SCAN
3. p183 最少需要從4個實例開始
4. Master和Shadow
5. GCS和GES
6. 緩存融會

附錄A 轉儲與調試