开始

1. SGA/SCN
2. 真正需要理解的仅仅3个进程：lgwr、dbwr、dbwN

redo和undo

1. http://www.wfuyu.com/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.wfuyu.com/db/崩溃致使内存中确当前状态没有更新到http://www.wfuyu.com/db/存储中时，就能够通过redo再做1次以确保事务完成；另外1方面，由于1个嵌套事务的失败，致使已完成的http://www.wfuyu.com/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的存在能够让会话在不应当看到数据的最新版本（未事务提交！）时去访问更旧的版本（预会话的1致性符合合）
   2. 读1致性：有限的ITL entries，超越的作为undo记录保存（往回倒带~）
   3. 回滚：将产生新的redo！（请对比代码管理系统里的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 转储与调试