Oracle核心技术 笔记（该书读得不仔细，需要找时间再细读~~）

Oracle核心技术

跳转至： 导航、 搜索

开始

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

redo和undo

1. 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被合并为一条日志记录，写入到redo缓冲区
   • 事务中的第一次修改包含一些特殊步骤*
   • （我的小结）理论上说来，redo日志写成功即意味着事务已经成功提交，这时如果数据库崩溃导致内存中的当前状态没有更新到数据库存储中时，就可以通过redo再做一次以确保事务完成；另外一方面，由于一个嵌套事务的失败，导致已完成的数据库更新需要回退，这时就需要undo，而undo本身有可能因存储于易失性区域崩溃而丢失，这时就需要把undo再通过undo的redo日志再做一遍以恢复数据到前一个一致状态

     从上面的描述可以看到，事务的实现依赖于数据修改是可逆的这一点，否则状态易失（如赋值操作、文件写操作）就不可能做到 一致性恢复

     而一致性恢复依赖于全局一致性快照（即MVCC）的创建，为此需要事务号、时间戳这些特殊的底层属性来实现，这可以参考CLojure语言中相关概念

4. why？undo记录阻止了其他用户查看我们正在改变的数据（中间临时状态）
   1. 其他用户可以通过undo得到记录的之前的一个版本（与他的事务视图相一
5. redo allocation latch：保护redo日志缓冲区（因为只有一个lgwr进行着串行的写操作）
   1. 所谓的latch其实就是Linux Kernel里类似spin_lock（自旋锁）的东西
6. p17 每个人都做一点点“额外的”工作（协作的开销？），就意味着他们可以在不同的地方同时工作，而不必经常在同一个地方竞争(contention)
7. redo simplicity
8. undo complexity
   1. undo的存在能够让会话在不应该看到数据的最新版本（未事务提交！）时去访问更旧的版本（与会话的一致性相符合）
   2. 读一致性：有限的ITL entries，超出的作为undo记录保存（往回倒带~）
   3. 回滚：将产生新的redo！（请对照代码管理系统里的revert操作，revert实际上产生一个新的commit）
      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-1555 “快照太旧”
   4. 大对象（LOB）
      1. 只需关心索引的事务和读一致性处理，特例：ORA-22924
5. 小结
   1. 一个ITL条目：xid: uba: SCN

锁与闩

1. 锁和pin：FCFS；闩和Mutex（10g+，替换pin）：随机抢占策略
2. 闩：保护共享内存
   1. 可共享
   2. 本质上是一个内存位置和一个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. 读一致性拷贝
   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 转储与调试